13

Non syscall's wrappers but something like snprintf(), dprintf()

vitaly.v.ch
  • 2,485
  • 4
  • 26
  • 36

4 Answers4

15

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.
Kimvais
  • 38,306
  • 16
  • 108
  • 142
  • that list is list of syscalls. I remember it pretty. but i need list of functions from glibc – vitaly.v.ch Jan 18 '10 at 13:03
  • 1
    Yes, that list consist mostly of system calls, but _that's what the GLIBC is; a __system__ interface_. I take it that the other standard C functions are __not__ signal safe as they are not listed here, or at least I am unable to find _any_ authoritative pointers to other (POSIX) standards listing them. – Kimvais Jan 18 '10 at 13:56
  • strcat, strcopy from GLIBC IS signal-safe. It's non-standard, but it is. I'm interested in more similar functions. – vitaly.v.ch Jan 19 '10 at 08:37
  • 2
    Source for the strcat / strcpy being signal-safe? – Kimvais Jan 19 '10 at 09:11
  • Yes sources of strcat, strcpy, strncpy, strcmp, strlen is signal-safe. – vitaly.v.ch Jan 20 '10 at 11:31
3

Finally latest versions of man 7 signal-safety contain interested list: signal-safety.7.html

vitaly.v.ch
  • 2,485
  • 4
  • 26
  • 36
  • It is important to note that a program that should also work in the future should only depend on functions documented as async signal safe, because functions that look safe from inspection of their source might be unsafe in a future version. Intent and commitment to async signal safety of the library author(s) is what matters here not current implementation. – textshell May 09 '22 at 20:28
1

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.

asveikau
  • 39,039
  • 2
  • 53
  • 68
0

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 and exec a separate utility (e.g. "pstack") to output a stack trace of your crashed task. When exec-ing (after fork-ing, in the child), you'll need to pass your process ID using getppid; and in the parent you'll need to wait for it to finish, before calling abort.

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().

Community
  • 1
  • 1
Tanz87
  • 1,111
  • 11
  • 10