[Mono-dev] [PATCH] Incorrect signal handling for Sys V signal handler

Burkhard Linke blinke at cebitec.uni-bielefeld.de
Thu Jan 27 10:06:06 EST 2011


Hi,

signal handlers registered with signal(3) behave in a somewhat different way 
for Sys V systems, e.g. Solaris. The manpage states that during the execution 
of the signal handler, the signal disposition is set to SIG_DFL. This raises 
two problems:

a) a possible race condition, if the same signal occurs during the execution 
of its signal handler

b) handling the signal a second time, since the manpage (and the 
implementation under Solaris..) does not reinstall the signal handler.

The attached test program uses Mono.Unix.Signal to catch signals. Executing it 
under Solaris/x86 running Mono 2.8.1, Mono 2.6.7 and the git master gives the 
following output:

running as process 29499
sending first HUP
sending second HUP
Hangup

The second SIGHUP is not catched by the signal handler, terminating the 
application (which is the default for SIGHUP).

The applied patch solves the problem by replacing signal(3) with sigset(3). 
sigset's semantic differs from signal's one; Instead of setting the signal to 
default handling, it adds the signal to the process/threads signal masks, 
executed the signal handler and restores the signal mask. Both problems 
mentioned above are solved. Test program output after applying the patch to 
git master:

running as process 172
sending first HUP
sending second HUP
sending third HUP
terminating


With best regards,
Burkhard Linke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono_sigset.diff
Type: text/x-diff
Size: 1893 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110127/c19947b0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.cs
Type: text/x-c++src
Size: 1089 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110127/c19947b0/attachment-0001.bin 


More information about the Mono-devel-list mailing list