[Libevent-users] Sigprocmask vs pthread_sigprocmask

[Niels Provos]

Hi Scott,

I looked at your patch and it seemed to work fine.  I submitted it to trunk.

Thank you,
 Niels.

On 2/24/07, Scott Lamb <slamb at slamb.org> wrote:
>
> On Feb 22, 2007, at 6:32 PM, Niels Provos wrote:
>
> > Do you have an addition to the regression test that would allow me to
> > verify that the new code works as intended?   If not, it would be most
> > appreciated :-)
>
> Happy Weekend, everyone. Looking at this again.
>
> There are two regression tests for this now:
>
> * test_simplesignal() tests a signal delivered while within select()/
> poll()/kevent()/epoll()/whatever.
> * test_immediatesignal() tests a signal delivered between signal_add
> () and event_loop().
>
> But you're referring to something more...proving that there would
> have been an evsignal_process() race if not for the reordering,
> right? That's hard to do through regression tests. I can think of
> only a couple ways to do that:
>
> (1) loop trying it many times, scheduling later delivery with alarms
> or through an additional thread (tests would depend on pthreads).
> Probably have to add some instrumentation to evsignal_process() to
> make it sleep at particular times to make it likely enough to happen
> on demand.
>
> (2) use debugging mechanisms to step through and deliver the signal
> at a particular time. I actually have done this programmatically
> before when proving a signal-handling library [*], but it was a lot
> of code and not exactly the most portable. Maybe it could be done
> more easily with gdb and expect, on at least gdb platforms.
>
> Would it help if I showed you a way to test it by hand?
>
> I've attached a simple test program that registers a handler for
> SIGUSR1 and SIGUSR2 which simply notes the signal was received. You
> can see the races I mention with gdb as follows:
>
> $ gcc -Wall sigtest.c -o sigtest -L.libs -levent
> $ LD_LIBRARY_PATH=.libs gdb ./sigtest
> ...
> (gdb) break evsignal_process
> Function "evsignal_process" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
>
> Breakpoint 1 (evsignal_process) pending.
> (gdb) run
> Starting program: /home/slamb/svn/libevent/sigtest
> (no debugging symbols found)
> <<<hit ctrl-C>>>
> Breakpoint 2 at 0x2aaaaaabf4a0: file signal.c, line 165.
> Pending breakpoint "evsignal_process" resolved
>
> Program received signal SIGINT, Interrupt.
> 0x000000318a4cd9d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
> (gdb) signal SIGUSR1
> Breakpoint 2, evsignal_process () at signal.c:165 (my line numbers
> are off because I've #ifdefed the two code blocks)
> <<<step until you hit a place you're suspicious of>>>
> (gdb) n
> 179             memset(evsigcaught, 0, sizeof(evsigcaught));
> (gdb) signal SIGUSR2
> Continuing with signal SIGUSR2.
> Received signal 10
>
> Here you can see that it only acknowledged receipt of SIGUSR1;
> SIGUSR2 was lost.
>
> If you do the same thing at any point in my modified evsignal_process
> (), you find instead:
>
> (gdb) signal SIGUSR2
> Continuing with signal SIGUSR2.
> Received signal 10
>
> Breakpoint 2, evsignal_process () at signal.c:165
> 165     {
> (gdb) c
> Continuing.
> Received signal 12
>
> [*] http://www.slamb.org/svn/repos/trunk/projects/sigsafe/tests/
> race_checker/
>
> --
> Scott Lamb <http://www.slamb.org/>
>
>
>