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 SIGUSR1Breakpoint 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 10Here 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/>
sigtest.c
Description: Binary data
_______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
