Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 592433 - #1966794 Java synchronization code locks on RHEL5.4
Summary: #1966794 Java synchronization code locks on RHEL5.4
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: java-1.6.0-openjdk
Version: 5.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Andrew Haley
QA Contact: BaseOS QE - Apps
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-14 20:28 UTC by Alan Matsuoka
Modified: 2018-10-27 12:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-07-13 16:44:32 UTC
Target Upstream Version:

Attachments (Terms of Use)
hung-jstack-voltdb.txt (deleted)
2010-05-14 20:30 UTC, Alan Matsuoka
no flags Details (deleted)
2010-05-14 20:30 UTC, Alan Matsuoka
no flags Details (deleted)
2010-05-14 20:31 UTC, Alan Matsuoka
no flags Details
sosreport-client-SR1966794.tar.bz2 (deleted)
2010-05-14 20:31 UTC, Alan Matsuoka
no flags Details

Description Alan Matsuoka 2010-05-14 20:28:42 UTC
Description of problem:
Client's java software running RHEL5.3/5.4(x64) on our Dell R610 (2x Xeon 5500) hangs sometimes. They haven't been able to reproduce the issue on distributions with newer kernels like Fedora 10/11 or Ubuntu 9.04 Server. It does reproduce on Centos 5.3/5.4
Client has given test code that reproduces the deadlock sometimes.Usually it takes 5 minues to hang, or not at all.
Client has provided jstack reports showing the deadlocked case and the dmesg output. Client has installed Openjdk jvm - 'java-1.6.0-openjdk-'. He has also provided core dump of the hung process.

How reproducible:
Not always

Steps to Reproduce:
Compile attached java code
$ javac -g
run it
$ java LBDLockPatternTest
If not hung in 10 minutes , kill the process and run again.
sometimes it hangs with stopping printing on screen.

  I tried to reproduce it on our internal server with rhel5.4 on 16x Xeon processor. The code gets hang 1 out of 10 times. I have taken sosreport and twice crash dumps of hang process on that system. I have installed glibc-debuginfo and java-1.6.0-openjdk-debuginfo packages to get more debug information. This process did not hang on rhel5.4 server with X2 Athlon when tried 20-30 times.

  Backtrace shows running thread is stuck at
#0  0x000000368720ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/
#1  0x00002b0cfa6a5c35 in Monitor::wait (this=0x21799c0, no_safepoint_check=false, timeout=0,as_suspend_equivalent=false)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/os/linux/vm/os_linux.hpp:279
#2  0x00002b0cfa7fb53b in VMThread::execute (op=0x41ad7870)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/share/vm/runtime/vmThread.cpp:587
#3  0x00002b0cfa6d0475 in ParallelScavengeHeap::mem_allocate (this=0x2181db0, size=4, is_noref=<value optimized out>, is_tlab=false, gc_overhead_limit_was_exceeded=0x41ad7947)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp:443
#4  0x00002b0cfa4f3d0f in instanceKlass::allocate_instance (this=<value optimized out>, __the_thread__=0x217c400)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:124
#5  0x00002b0cfa724009 in OptoRuntime::new_instance_C (klass=0x2aaaae8c9a88, thread=<value optimized out>)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/share/vm/opto/runtime.cpp:173
#6  0x00002aaaab58a307 in ?? ()
#7  0x000000000217c400 in ?? ()
#8  0x00002b0cfa4f3b4e in instanceKlass::allocate_instance (this=<value optimized out>, __the_thread__=0x2aaab39f0198)
   at /usr/src/debug/icedtea6-1.2/openjdk/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216
#9  0x00002aaaae8c9a88 in ?? ()
#10 0x0000000000000000 in ?? ()

Attached Client sosreport. client's core dump is on at  /incoming/core-SR1966794-client.tar.gz
Core dump on is on at  /incoming/core-SR1966794-ibm-x3650m2-1.tar.gz  /incoming/sosreport-ibm-x3650m2-1-SR1966794.tar.bz2

client had talk with other vendors.

The Sun/Oracle JDK engineers have confirmed this is a bug in the JDK:
It has been fixed in the recent Official Oracle/Sun Java JDK 1.6u18:   defect 6822370

Client verified that the fix is NOT in the latest OpenJDK release and is not yet on the trunk of the OpenJDK source. OpenJDK mailing list people told it will make it into b19, whenever that comes out.

Now, client is able to run our software on RHEL5 with the latest release of the official JDK, but not with OpenJDK

Comment 1 Alan Matsuoka 2010-05-14 20:30:19 UTC
Created attachment 414160 [details]

Comment 2 Alan Matsuoka 2010-05-14 20:30:47 UTC
Created attachment 414161 [details]

Comment 3 Alan Matsuoka 2010-05-14 20:31:14 UTC
Created attachment 414162 [details]

Comment 4 Alan Matsuoka 2010-05-14 20:31:55 UTC
Created attachment 414163 [details]

Comment 6 Andrew Haley 2010-07-13 16:44:32 UTC
1:1.6.0-1.9.b16 has been pushed to RHEL 5.3, 5,4, and 5.5, and already has this bug fixed.  Please reopen if these is still a problem after updating.

Note You need to log in before you can comment on or make changes to this bug.