JDK-6244106 : IA64 Hang occurs at malloc/free in RHEL AS 3
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_05
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_redhat_3.0
  • CPU: itanium
  • Submitted: 2005-03-22
  • Updated: 2014-02-27
  • Resolved: 2006-10-23
Related Reports
Duplicate :  
Description
A customer  has  found hang in malloc/free thread in JRE1.4.2 for
RHEL AS3 (IA64).

---- Thread Dump ----
.........

Thread 2 (Thread 2305843010565911168 (LWP 2829)):

#0  0xa000000000010641 in ?? ()
#1  0x2000000000270ef0 in __lll_lock_wait () from /lib/tls/libc.so.6.1
#2  0x2000000000186b00 in free () from /lib/tls/libc.so.6.1
#3  0x2000000000d8f830 in os::free () from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#4  0x2000000000e0f350 in PerfMemory::delete_memory_region ()
   from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#5  0x2000000000e0d460 in PerfMemory::destroy ()
   from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#6  0x2000000000e0d540 in perfMemory_exit () from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#7  0x2000000000d94190 in os::abort () from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#8  0x2000000000d91780 in os::handle_unexpected_exception ()
   from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#9  0x2000000000d9bec0 in JVM_handle_linux_signal ()
   from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#10 0x2000000000d974a0 in signalHandler () from /tmp/c/fjvm142_05B11/jre/lib/ia64/fjvm/libjvm.so
#11 <signal handler called>
#12 0x2000000000185800 in _int_free () from /lib/tls/libc.so.6.1
#13 0xc000000000000610 in ?? ()
#14 0x2000000000186a60 in free () from /lib/tls/libc.so.6.1

......
----

According to the above, the hang-up scenario seems as follows.

   Signal generated at free()
   ==> JVM signal handler
   ==> os::abort()
   ==> perfMemory_exit
   ==> free()
   < Here, Hang occurs !! >

As for JRE in Solaris edition, customer works around this issue by checking
whether or not some thread get  the lock, "__malloc_lock".
However,  they can not apply the same workaround to linux edition
because system library in linux  is different from that in Solaris.

###@###.### 2005-03-22 09:30:37 GMT

Comments
EVALUATION The description from Fujitsu is correct. Signal handlers should only use async-safe functions. I rewrote the fatal error handler code in 1.5 to remove any asynchronous unsafe functions from its call path, it's been explicitly tested with crashes happened inside malloc/free holding the malloc lock. It is bug 4515367, which should be backported to 1.4.2 very soon. ###@###.### 2005-03-22 19:11:48 GMT
22-03-2005