sighals and sockets

[Andrew Haley]

Gladish, Jacob writes:
 > 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. 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? Are there any other uses of the ignore on the SIGPIPE
 > other that the socket writer?
 > 
 > I still have not discovered why the application has crashed. But here's
 > a snippet of the stack. This is 3.3.1

syslog() has a critical section in which it does all the messing with
signals.  libc doesn't stash the user sigaction in a per thread
variable: it's just an array __sighandler[signo].

It seems from your stack trace that __sighandler[13] is set to
0x00000003.  A GDB watchpoint on that memory can tell you how that
happens.

Andrew.