sighals and sockets

Wed Aug 4 20:42:00 GMT 2004

Gladish, Jacob wrote:
>I've been trying to track down a bug in my code for a few days now and I
>was looking at a pretty strange stack. It looked like the
>PlainSocketImpl::write would get as far as __libc_write, enter a signal
>handler, segv, enter the segv signal handler, then recurse forever until
>the process crashed.
>Sounds like write() is segfaulting for some reason, and the segv is 
being caught by libgcj's segv handler, which converts segv's into 
NullPointerExceptions.
> It was pretty confusing because the runtime sets an
>ignore on SIGPIPE and the args going into the write looked fine from
>gdb. After some thought, I realized that since the app uses a good deal
>of native (CNI) code, it's possible someone else is setting a sighandler
>for SIGPIPE. It turns out that the syslog call will do just that in
>glibc. It installs a temporary sighandler for PIPE, then restores
>whatever was there before returning to the caller. So there's a race
>condition that exists between a thread writing to a socket in the java
>runtime and a thread calling syslog. The only problem I see here is that
>the socket writing thread may inadvertantly close the syslog connection,
>which would then be re-stablished the next time someone calls syslog. 
>>Would it be safer to use the send(...) call instead of the write(...) in
>the socket code? 
>I don't think so. send() can potentially generate a SIGPIPE just like 
write(), according to my glibc docs.
>I still have not discovered why the application has crashed. But here's
>a snippet of the stack. This is 3.3.1
>>-jake
>>>(gdb) bt -40
>#9158 0x2ac5106e in uw_frame_state_for (context=0x797fea3c,
>fs=0x797fe97c) at ../../gcc/gcc/unwind-dw2.c:939
>>
It looks like it is crashing in the libgcc unwinder itself (trying to 
throw the NullPointerException), hence the infinite recursion. A problem 
with the dwarf2 unwind info on this platform, perhaps? Do the various 
exceptions tests in the libjava test suite run ok for you?
Regards
Bryce