je besoin d'une liste de Async-Signal-Safe Fonctions de glibc

Question

emballages de

non syscall, mais quelque chose comme snprintf(), dprintf()

Answer 1

Enfin les dernières versions de man 7 signal-safety contiennent la liste intéressée: signal-safety.7.html

Answer 2

Je suis assez sûr que vous devez voir le documentation

Modifier: Que diriez-vous de this list alors?

De 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. 

Answer 3

Cela semble difficile à déterminer, car vous ne savez pas quelle fonction dangereuse au hasard une routine de bibliothèque peut décider d'appeler. La liste peut également différer entre les différentes versions de la glibc, ou si vous l'apportez à un autre système de type Unix. Il semblerait que vous deviez analyser beaucoup de piles d'appels pour trouver la réponse, et même cela pourrait être un peu hésitant d'une version à l'autre, de la distribution à la distribution. Peut-être que vous ne cherchez pas d'approches de conception alternatives, mais il semble que la meilleure stratégie serait: si votre programme a une boucle d'événement, rendez le gestionnaire de signal très stupide et définissez juste un état que la boucle d'événement va ramasser . De cette façon, vous faites le travail significatif en dehors du gestionnaire de signal.

Exemple: Disons que vous avez une boucle poll() quelque part. Peut-être que vous pourriez inclure un tuyau que le gestionnaire de signal peut écrire. Alors la boucle poll() fait un travail non-trivial basé sur être signalé par cela.

Answer 4

J'ai besoin de cela dans le gestionnaire SIGSEGV APRÈS un accident d'application.

Je veux détendre pile sur le crash

Si vous essayez de capturer une trace de la pile:

• Généralement abort provoquerait une décharge de base, qui peut être exécuté par un débogueur produire la trace de la pile.

• En variante, un brut (mais le signal de sécurité) façon de le faire serait de fork et exec un utilitaire distinct (par exemple « de pstack ») pour délivrer en sortie une trace de pile de la tâche est écrasé. Lorsque exec -ing (après fork -ing, dans l'enfant), vous devrez passer votre ID de processus en utilisant getppid; et dans le parent, vous aurez besoin de wait pour finir, avant d'appeler abort.

D'autre part, si vous essayez de faire une sortie « propre » après SIGSEGV (C++ par exemple, assurer Destructeurs obtenir appelé, etc.) - alors vous devriez être averti que POSIX dit:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_02:

Le comportement d'un processus est indéfini après qu'il ignore un SIGFPE, SIGILL, SIGSEGV, ou un signal de SIGBUS qui n'a pas été généré par kill(), sigqueue() ou augmenter().

et http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03:

Le comportement d'un processus est indéfini après qu'il revient normalement à partir de une fonction de signal de capture pour un SIGBUS, SIGFPE, SIGILL, ou un signal SIGSEGV qui n'a pas été généré par kill(), sigqueue() ou raise().