Expand and rework the text a little, in particular adding
a reference to sigreturn(2) as a source of further
information about the ucontext argument.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove reference to non-standard "tlpi_hdr.h" and replace calls to
functions that were declared in this header.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently, the backtrace(3) manual page says this about backtrace_symbols_fd():
back‐
trace_symbols_fd() does not call malloc(3), and so can be
employed in situations where the latter function might fail.
However, I watched a video of a presentation about signal handling and
the speaker was saying that calling backtrace() can trigger a call to
malloc - indirectly. That happens because the backtrace*() functions
are part of libgcc, which gets dynamically loaded whenever needed;
dynamic loading would, in turn, trigger a malloc. The talk can be
found here: http://free-electrons.com/pub/video/2008/ols/ols2008-gilad-ben-yossef-fault-handlers.ogg
I decided to test it out, and it seems that this is still true (at
least on Ubuntu 12.04). I compiled the attached program (I used
CXXFLAGS = '-Wall -g -std=c++0x', the -std= part is not really needed)
and ran it through gdb, putting a breakpoint on the line where
backtrace is called. When that breakpoint is hit, I set a breakpoint
on malloc, continued and voila:
Breakpoint 2, __GI___libc_malloc (bytes=36) at malloc.c:2910
2910 malloc.c: No such file or directory.
(gdb) bt
"/lib/x86_64-linux-gnu/libgcc_s.so.1") at dl-load.c:162
"libgcc_s.so.1", type=2, trace_mode=0, mode=-1879048191,
nsid=<optimized out>) at dl-load.c:2473
errstring=0x7fffffffdd00, mallocedp=0x7fffffffdd0f,
operate=0x7ffff7ded700 <dl_open_worker>, args=0x7fffffffdcb0) at
dl-error.c:178
"libgcc_s.so.1", mode=-2147483647, caller_dlopen=0x7ffff7b260a9,
nsid=-2, argc=1, argv=<optimized out>, env=0x7fffffffe068) at
dl-open.c:639
errstring=0x7fffffffded0, mallocedp=0x7fffffffdeef,
operate=0x7ffff7b4bc20 <do_dlopen>, args=0x7fffffffdeb0) at
dl-error.c:178
operate=0x7ffff7b4bc20 <do_dlopen>) at dl-libc.c:48
out>) at dl-libc.c:165
../sysdeps/x86_64/../ia64/backtrace.c:104
Reviewed-by: Walter Harms <wharms@bfs.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rahul, the existing sentence could be read as
meaning that resources of joined and terminated detached
threads are freed at only at process termination. Eliminate
that possible misreading.
Reported-by: Rahul Bedarkar <rpal143@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since 4.13, errors from writeback are more reliably reported
to all file descriptors that might be relevant.
Add notes to this effect, and also add detail about ENOSPC and
EDQUOT which can be delayed in a similar many to EIO - for NFS
in particular.
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>