This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sighals and sockets


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]