Bug 81354

Summary: java 1.3.1_06 always hangs on exit
Product: [Retired] Red Hat Public Beta Reporter: Daniel Resare <noa-bugzilla-redhat>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: phoebeCC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-09 00:26:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 79579    

Description Daniel Resare 2003-01-08 14:30:25 UTC
Description of problem:

The java 1.3.1_06 (the latest patchlevel available from sun) runtime doesn't
doesn't exit propely on phoebe.

This problem does not affect java-1.4.1_01, however it is a big problem since
lots of products and code are dependant on a working java-1.3.x environment

Version-Release number of selected component (if applicable):
glibc-2.3.1-21

How reproducible:
always

Steps to Reproduce:
1. download the jdk1.3.1_06 rpm from java.sun.com
2. install the rpm
3. run for example '/usr/java/jdk1.3.1_06/bin/java -version'
    
Actual results:
the process doesn't exit, 'killall java' doesn't help, but 'killall -KILL java'
works.

Expected results:
version infomation then exit

Additional info:
If i fire up the java binary in gdb and ctrl-c when the process hangs i always
end up here:

#0  0x4003f45c in siglongjmp () from /lib/i686/libpthread.so.0
#1  0x401a517b in Monitor::wait () from jre/lib/i386/client/libjvm.so
#2  0x401eb899 in VMThread::execute () from jre/lib/i386/client/libjvm.so
#3  0x401ddcb4 in Threads::destroy_vm () from jre/lib/i386/client/libjvm.so
#4  0x40156c8d in jni_DestroyJavaVM () from jre/lib/i386/client/libjvm.so
#5  0x080493b5 in main ()

Comment 1 Jakub Jelinek 2003-01-09 00:26:41 UTC
It is JDK 1.3.1 bug. You can use LD_ASSUME_KERNEL=2.2.5 in the environment
to workaround this.