Non syscall's wrappers but something like snprintf(), dprintf()
问题:
回答1:
I am pretty sure you have to see the documentation
Edit: How about this list then?
From man signal
:
NOTES
The effects of this call in a multi-threaded process are unspecified.
The routine handler must be very careful, since processing elsewhere
was interrupted at some arbitrary point. POSIX has the concept of "safe
function". If a signal interrupts an unsafe function, and handler
calls an unsafe function, then the behavior is undefined. Safe func-
tions are listed explicitly in the various standards. The POSIX.1-2003
list is
_Exit() _exit() abort() accept() access() aio_error() aio_return()
aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect()
creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdata-
sync() fork() fpathconf() fstat() fsync() ftruncate() getegid()
geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getp-
pid() getsockname() getsockopt() getuid() kill() link() listen()
lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe()
poll() posix_trace_event() pselect() raise() read() readlink() recv()
recvfrom() recvmsg() rename() rmdir() select() sem_post() send()
sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid()
shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sig-
fillset() sigismember() signal() sigpause() sigpending() sigprocmask()
sigqueue() sigset() sigsuspend() sleep() socket() socketpair() stat()
symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetp-
grp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun()
timer_gettime() timer_settime() times() umask() uname() unlink()
utime() wait() waitpid() write().
According to POSIX, the behaviour of a process is undefined after it
ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
the kill(2) or the raise(3) functions. Integer division by zero has
undefined result. On some architectures it will generate a SIGFPE sig-
nal. (Also dividing the most negative integer by -1 may generate
SIGFPE.) Ignoring this signal might lead to an endless loop.
See sigaction(2) for details on what happens when SIGCHLD is set to
SIG_IGN.
The use of sighandler_t is a GNU extension. Various versions of libc
predefine this type; libc4 and libc5 define SignalHandler, glibc
defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t.
回答2:
This seems hard to determine, as you don't know what random unsafe function a library routine might decide to call. The list also might different between different versions of glibc, or if you take it to another Unix-like system. Seems like you'd have to analyze a lot of call stacks to find the answer, and even that may be a bit shaky from version to version, distro to distro.
Maybe you are not looking for alternative design approaches, but it seems like a better strategy would be: if your program has an event loop, make the signal handler very stupid and just setting some state that the event loop will pick up. That way you do the meaningful work outside of the signal handler.
Example: Let's say you've got a poll()
loop somewhere. Maybe you could include a pipe that the signal handler can write to. Then the poll()
loop does some non-trivial work based on being signaled by that.
回答3:
I need this in SIGSEGV handler AFTER crash of application.
I want unwind stack on crash
If you're trying to capture a stack trace:
Typically
abort
would cause a core dump, which can be run through a debugger to produce the stack trace.Alternatively, a crude (but signal-safe) way of doing so would be to
fork
andexec
a separate utility (e.g. "pstack") to output a stack trace of your crashed task. Whenexec
-ing (afterfork
-ing, in the child), you'll need to pass your process ID usinggetppid
; and in the parent you'll need towait
for it to finish, before callingabort
.
On the other hand, if you're trying to do a "clean" exit after SIGSEGV (e.g. ensuring C++ destructors get called, etc.) -- then you should be warned that POSIX says:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_02:
The behavior of a process is undefined after it ignores a SIGFPE, SIGILL, SIGSEGV, or SIGBUS signal that was not generated by kill(), sigqueue(), or raise().
and http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03:
The behavior of a process is undefined after it returns normally from a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(), sigqueue(), or raise().
回答4:
Finally latest versions of man 7 signal-safety
contain interested list: signal-safety.7.html