Date: Tue, 6 Dec 2005 14:36:20 -0800 (PST) From: freebsd@spatula.net To: bug-followup@FreeBSD.org Cc: freebsd-java@freebsd.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Message-ID: <20051206141650.O2752@turing>
next in thread | raw e-mail | index | archive | help
This is still happening on FreeBSD 6.0-STABLE as of 12/6/2005.
World and kernel were compiled without any CPUTYPE or CFLAGS options, as
was Java.
This problem is trivial to reproduce. One merely has to start httpd.sh in
Resin 3.0 with no arguments, wait for the JVM to start running, and hit
^Z or ^C.
The process then goes into an infinite loop in kse_release. truss -p
shows the following:
kse_release(0x8056f44) = 0 (0x0)
kse_release(0x8056f44) = 0 (0x0)
kse_release(0x8056f4c) = 0 (0x0)
kse_release(0x8056f44) = 0 (0x0)
kse_release(0x8056f44) = 0 (0x0)
kse_release(0x8056f4c) = 0 (0x0)
ktrace shows a bit more detail of the infinite loop:
21357 java CALL gettimeofday(0xbf275e70,0)
21357 java RET gettimeofday 0
21357 java CALL gettimeofday(0xbf275ec0,0)
21357 java RET gettimeofday 0
21357 java CALL kse_release(0x8056f4c)
21357 java RET kse_release 0
21357 java CALL gettimeofday(0xbf275e70,0)
21357 java RET gettimeofday 0
21357 java CALL gettimeofday(0xbf275ec0,0)
21357 java RET gettimeofday 0
21357 java CALL kse_release(0x8056f4c)
21357 java RET kse_release 0
gcore -s 21357; gdb /usr/local/jdk14/bin/java core.21357 shows:
Cannot get thread info: generic error
#0 0x4809f1af in pthread_testcancel () from /usr/lib/libpthread.so.2
#1 0x480a01dd in __error () from /usr/lib/libpthread.so.2
#2 0x4808adeb in pthread_getschedparam () from /usr/lib/libpthread.so.2
#3 0x4808feef in pthread_create () from /usr/lib/libpthread.so.2
#4 0x48465f10 in os::create_thread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#5 0x484afb28 in JavaThread::JavaThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#6 0x483f927c in JVM_StartThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
followed by a smashed-looking stack for about 60 frames, and then:
#65 0x485735c0 in __JCR_LIST__ () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
#66 0x4a3c20d7 in ?? ()
#67 0xbf073d00 in ?? ()
#68 0xbf073d48 in ?? ()
#69 0x4839032b in JavaCalls::call_helper () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so
Previous frame inner to this frame (corrupt stack?)
Note that the valid-looking portion of the stack trace still isn't valid
higher than pthread_create(), though this could have still been a result
of the process still making calls while gcore was running, since the
process does not respond to the STOP signal.
I'm inclined to suspect that this is a Java bug, considering the smashed
stack.
Nick
--
"The aptly-named morons.org is an obscenity-laced screed..."
-- Robert P. Lockwood, Catholic League director of research
Nick Johnson, version 2.1 http://web.morons.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051206141650.O2752>