This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
FW: signals and sockets
- From: "Gladish, Jacob" <Jacob dot Gladish at netapp dot com>
- To: <java at gcc dot gnu dot org>
- Date: Thu, 5 Aug 2004 14:39:08 -0700
- Subject: FW: signals and sockets
>
> 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.
>
I saw the same thing and was wondering myself how that could possibly be
set to 3. I still have no clue.
I did discover that you cannot use syslog with the gcj java runtime. If
you do, then a race condition exists with the syslog. It's possible that
a sighandler with address "1" (SIG_IGN) might get called because of the
temporary installation of the syslog's sighandler and the restoration.
The check to see if a sighandler is installed caould pass while syslog
has it's handler installed, then restores it to the SIG_IGN, before the
actual call, which would result in a call to a sighandler with address
1.
-jake