Comment diagnostiquer/tracer "sendsig: useracc a échoué." problème dans HP-UX

Question

Je suis en train de compiler Ruby 1.9.1-p0 sur HP-UX. Après un petit changement à ext/pty.c, il compile avec succès, mais avec un lot de messages d'avertissement (environ 5K). Quand je lance les auto-tests en utilisant « make test », il se bloque et core-dumps avec l'erreur suivante:

sendsig: useracc failed. 0x9fffffffbf7dae00 0x00000000005000

Pid 3044 was killed due to failure in writing the signal context - possible stack overflow.

Illegal instruction

De googler ce problème, l'instruction illégale est juste un signal que le système utilise pour tuer le processus, et non lié au problème. Il semblerait qu'il y ait un problème avec le rétablissement du contexte lors de l'appel du gestionnaire de signal. Apporter le core dans gdb ne montre pas une pile particulièrement profonde, donc je ne pense pas que le "stack overflow" soit correct non plus.

La sortie pile de gdb Backtrace ressemble à ceci:

#0 0xc00000000033a990:0 in __ksleep+0x30() from /usr/lib/hpux64/libc.so.1 
#1 0xc0000000001280a0:0 in __mxn_sleep+0xae0() 
    from /usr/lib/hpux64/libpthread.so.1 
#2 0xc0000000000c0f90:0 in <unknown_procedure> + 0xc50() 
    from /usr/lib/hpux64/libpthread.so.1 
#3 0xc0000000000c1e30:0 in pthread_cond_timedwait+0x1d0() 
    from /usr/lib/hpux64/libpthread.so.1 

Answer 1

répondre à ma propre question:

Le problème est que la pile allouée était trop petite. Donc, c'était vraiment un débordement de pile. La fonction sendsig() préparait une structure de contexte à copier de l'espace noyau vers l'espace utilisateur. La fonction useracc() vérifie qu'il y a suffisamment d'espace à l'adresse spécifiée pour le faire.

Le code Ruby 1.9.1-p0 utilisait PTHREAD_STACK_MIN pour allouer la pile pour tous les threads créés. Selon la documentation HP-UX, sur Itanium, il s'agit de 256 Ko, mais lorsque j'ai vérifié les fichiers d'en-tête, il n'y en avait que 4 Ko. Le message d'erreur de useracc() indiquait qu'il essayait de copier 20 Ko. Par conséquent, si un thread reçoit un signal, il n'aura pas assez d'espace pour recevoir le contexte de signal sur sa pile.