Date: Wed, 10 Aug 2005 12:29:09 -0700 (PDT) From: Nick Johnson <freebsd@spatula.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Message-ID: <20050810192909.01E56A92F@turing.morons.org> Resent-Message-ID: <200508101930.j7AJUBZp063712@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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 >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 10 19:30:10 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Nick Johnson >Release: FreeBSD 5.4-STABLE i386 >Organization: morons.org >Environment: FreeBSD 5.4-stable as of August 5, 2005; Java from /usr/ports 1.4.2-p7, same date Resin 3.0.14 from http://www.caucho.com/download/index.xtp Intel P4, HTT disabled, non-SMP kernel 2GB RAM >Description: 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/libpthread.so.1 #1 0x4808fc05 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x48093be0 in pthread_setconcurrency () from /usr/lib/libpthread.so.1 #3 0x4808a405 in _nanosleep () from /usr/lib/libpthread.so.1 #4 0x4808a4fe in nanosleep () from /usr/lib/libpthread.so.1 #5 0x4808162b in select () from /usr/lib/libpthread.so.1 #6 0x48460e09 in os_sleep () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #7 0x48460fcd in os::sleep () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #8 0x484a9933 in WatcherThread::run () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #9 0x4845f1d7 in _start () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #10 0x48083b09 in pthread_create () from /usr/lib/libpthread.so.1 #11 0x4813f85b in _ctx_start () from /lib/libc.so.5 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/libpthread.so.1 #1 0x48098293 in __error () from /usr/lib/libpthread.so.1 #2 0x4808493a in pthread_yield () from /usr/lib/libpthread.so.1 #3 0x48083a11 in pthread_create () from /usr/lib/libpthread.so.1 #4 0x4808348d in pthread_create () from /usr/lib/libpthread.so.1 #5 0x484609fd in os::create_thread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #6 0x484aa430 in JavaThread::JavaThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so #7 0x483f3f68 in JVM_StartThread () from /usr/local/jdk1.4.2/jre/lib/i386/client/libjvm.so 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. >How-To-Repeat: Build Java from ports. Download Resin OpenSource (link in the "Environment" section of this PR) Edit Resin's bin/httpd.sh, setting RESIN_HOME, JAVA_HOME and args=-J-Djaa.net.preferIPv4Stack=true Run httpd.sh. 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. Run httpd.sh. 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 >Fix: Workaround is to configure /etc/libmap.conf to use libc_r for Java. Fix is unknown. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050810192909.01E56A92F>