JDK-6321507 : atg's client hangs with mustang b50 on linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-09-08
  • Updated: 2010-08-06
  • Resolved: 2005-09-09
Related Reports
Duplicate :  
Description
with Mustang b50, atg's client, urlhammer, hung after a few hours' run.
The problem was observed on both SLES9SP1 (2.6.5-7.97-smp) and RHEL4.0(2.6.9-5.ELsmp), 
and on both AMD 64 bits OS and regular 32 bits OS.

jvm flags used: -server -XX:CompileThreshold=100 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
Test machine: jtg-amd3 ( SLES9SP1, kernel 2.6.5-7.97-smp)

Thread 111 (Thread 1080232288 (LWP 26004)):
#0  0x0000002a95675702 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/tls/libpthread.so.0
#1  0x0000002a95675b45 in pthread_cond_wait@GLIBC_2.2.5 ()
   from /lib64/tls/libpthread.so.0
#2  0x0000002a95efedb7 in os::Linux::safe_cond_wait ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#3  0x0000002a95ee9598 in Monitor::wait ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#4  0x0000002a95ca2b90 in CMSCollector::waitForForegroundGC ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#5  0x0000002a95ca2425 in CMSCollector::collect_in_background ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#6  0x0000002a95caf5e7 in ConcurrentMarkSweepThread::run ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#7  0x0000002a95effc4e in java_start ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#8  0x0000002a956738e2 in start_thread () from /lib64/tls/libpthread.so.0
#9  0x0000002a9593c863 in thread_start () from /lib64/tls/libc.so.6
#10 0x0000000000000000 in ?? ()
...


Thread 110 (Thread 1081280864 (LWP 26005)):
#0  0x0000002a95677a0b in __lll_mutex_lock_wait ()
   from /lib64/tls/libpthread.so.0
#1  0x0000000000000002 in ?? ()
#2  0x0000000000000000 in ?? ()
#3  0x0000002a9567577f in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/tls/libpthread.so.0
#4  0x0000002a95675b45 in pthread_cond_wait@GLIBC_2.2.5 ()
   from /lib64/tls/libpthread.so.0
#5  0x0000002a95efedb7 in os::Linux::safe_cond_wait ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#6  0x0000002a95ee9598 in Monitor::wait ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#7  0x0000002a95ca1aa0 in CMSCollector::acquire_control_and_collect ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#8  0x0000002a95ca16bf in ConcurrentMarkSweepGeneration::collect ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#9  0x0000002a95cf9eaf in GenCollectedHeap::do_collection ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#10 0x0000002a95c86696 in GenCollectorPolicy::satisfy_failed_allocation ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#11 0x0000002a95cfa12e in GenCollectedHeap::satisfy_failed_allocation ()
#12 0x0000002a96028dc2 in VM_GenCollectForAllocation::doit ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#13 0x0000002a9603181a in VM_Operation::evaluate ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#14 0x0000002a96030f82 in VMThread::evaluate_operation ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#15 0x0000002a960311cf in VMThread::loop ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#16 0x0000002a96030d5e in VMThread::run ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#17 0x0000002a95effc4e in java_start ()
   from /usr/j2se/jre/lib/amd64/server/libjvm.so
#18 0x0000002a956738e2 in start_thread () from /lib64/tls/libpthread.so.0
#19 0x0000002a9593c863 in thread_start () from /lib64/tls/libc.so.6
...

how to reproduce the problem.
1. log into jtg-amd3
2. export JAVA_HOME=<java home>
3. /bs/runatg.ksh -server -XX:CompileThreshold=100 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
4. the log files will be generated under /bt/atg*
   check if the timestamp of the client log "run.atg.out" is up-to-date.

Comments
EVALUATION looks like this is fixed in latest main baseline bits.
09-09-2005