bin/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec

Nick Johnson freebsd at
Wed Aug 10 19:30:12 GMT 2005

>Number:         84778
>Category:       bin
>Synopsis:       libpthread busy loop/hang with Java when handling signals and Runtime.exec
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 10 19:30:10 GMT 2005
>Originator:     Nick Johnson
>Release:        FreeBSD 5.4-STABLE i386
FreeBSD 5.4-stable as of August 5, 2005;
Java from /usr/ports 1.4.2-p7, same date
Resin 3.0.14 from
Intel P4, HTT disabled, non-SMP kernel


Delivering the Java VM a ^C or ^Z causes it to stop responding and begin consuming all available CPU.  When this 
happens, a ktrace reveals repeated kse_release calls followed immediately by RET kse_release 0.  A stack trace
from a gcore of the running Java process shows the last stack frame is a call to pthread_testcancel():

#0  0x48097353 in pthread_testcancel () from /usr/lib/
#1  0x4808fc05 in pthread_mutexattr_init () from /usr/lib/
#2  0x48093be0 in pthread_setconcurrency () from /usr/lib/
#3  0x4808a405 in _nanosleep () from /usr/lib/
#4  0x4808a4fe in nanosleep () from /usr/lib/
#5  0x4808162b in select () from /usr/lib/
#6  0x48460e09 in os_sleep () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#7  0x48460fcd in os::sleep () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#8  0x484a9933 in WatcherThread::run () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#9  0x4845f1d7 in _start () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#10 0x48083b09 in pthread_create () from /usr/lib/
#11 0x4813f85b in _ctx_start () from /lib/

Similarly, if Resin is configured to use an external compiler (like Jikes), the same thing appears to happen on the 
Runtime.exec() call, again with the last stack frame being a call to pthread_testcancel:

#0  0x48097353 in pthread_testcancel () from /usr/lib/
#1  0x48098293 in __error () from /usr/lib/
#2  0x4808493a in pthread_yield () from /usr/lib/
#3  0x48083a11 in pthread_create () from /usr/lib/
#4  0x4808348d in pthread_create () from /usr/lib/
#5  0x484609fd in os::create_thread () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#6  0x484aa430 in JavaThread::JavaThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/
#7  0x483f3f68 in JVM_StartThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/

If the linker is configured using libmap.conf to use libc_r instead, both of these problems go away.  Fortunately
both of these problems seem quite easy to reproduce.

Build Java from ports.
Download Resin OpenSource (link in the "Environment" section of this PR)
Edit Resin's bin/, setting RESIN_HOME, JAVA_HOME and
Run  Wait for Resin to start, then hit ^C or ^Z and watch what happens to the Java process.

Build Jikes from ports.
Edit conf/resin.conf and set the java compiler to the full path to Jikes.
Point your browser at the Resin httpd (typically on port 8080) and load any JSP page (which requires use of the
compiler) and watch what happens to the Java process


Workaround is to configure /etc/libmap.conf to use libc_r for Java.  Fix is unknown.


More information about the freebsd-bugs mailing list