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

[Miguel de Icaza]

Hello,

    I have other concerns about this use of signal.   Perhaps it
should be using sigaction with the proper flags to configure how we
want signals to be delivered instead.

Miguel

On Thu, Jan 27, 2011 at 12:52 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:
> I can't speak to the rest of the patch, but the mono/support patch can't go in as-is, as mono/support/signal.c is also built for Windows (it's part of MPH_C_SOURCE in mono/support/Makefile.am, which is included in the HOST_WIN32 build).
>
> MSVCRT.DLL DOES contain signal(3); it does NOT contain sigset(3), and thus this would break the Windows build.
>
> Furthermore, OSX doesn't provide sigset(3) either, so this would break the OSX build as well.
>
> You should patch configure.in to check for sigset, and wrap the sigset calls with HAVE_SIGSET, otherwise keep the existing signal calls.
>
>  - Jon
>
> On Jan 27, 2011, at 10:06 AM, Burkhard Linke wrote:
>
>> 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
>> <mono_sigset.diff><Main.cs>_______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>