JDK-8004285 : Crash during start up in _int_malloc() (libc) due to SIGSEGV
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24,hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2012-12-03
  • Updated: 2013-09-12
  • Resolved: 2013-06-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
hs24Resolved
Related Reports
Duplicate :  
JDK-8003841 - SIGSEGV errors in _int_malloc for nightly tests alllinelocations002, threadgroups001, and redefineclasses030
Duplicate :  
JDK-8003843 - Nightly run of test ArgumentValues001 failed with SIGSEGV in arena_get2().
Duplicate :  
JDK-7173959 - Jvm crashed during coherence exabus (tmb) testing
Duplicate :  
JDK-8005151 - Jvm crashed during coherence exabus (tmb) testing
Relates :  
JDK-8003841 - SIGSEGV errors in _int_malloc for nightly tests alllinelocations002, threadgroups001, and redefineclasses030
Relates :  
JDK-7173959 - Jvm crashed during coherence exabus (tmb) testing
Relates :  
JDK-8003843 - Nightly run of test ArgumentValues001 failed with SIGSEGV in arena_get2().
Description
Have seen occasional crashes during start up when running on Exalogic x2-2. The crash is reproducible but happens very seldom, something like 1 in 10000. It is reproducible on both jdk 7 and 8.

The way I reproduce it is by running HelloCrash (like HelloWorld) over and over:
while true; do java -Xms4096m -Xmx4096m HelloCrash; sleep 0.2; done

The crash always seems to happen in _int_malloc and then the JVM often crashes again during crash handling. The stack trace before the call to malloc differs and I have not seen any real pattern. 

The Exalogic is running:
Linux sthex01-srv06 2.6.32-400.1.1.el5uek #1 SMP Mon Jun 25 20:25:08 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

jdk7:
java version "1.7.0_12-ea"
Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b03)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b25, mixed mode)

jdk8:
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b66)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b10, mixed mode)

Will attach some hs_err-files and cores. If needed I can provide more cores later, have around 50.
Comments
Why is there no "Resolved in build" information for this bug? Why does this issue seem to have so many bugs associated with it?
30-01-2013
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e1d9b04b560b
08-01-2013
While working on issue JDK-7173959, the GC team sometimes ran into the issue reported here. We had some discussions around their problem and found a potential memory mapping problem. I've used a patched VM with a fix for that problem to see if it solves this issue as well. The over night run looks very promising since no crashes have been seen with the patch VM, while an unpatch VM crashed several times.
11-12-2012
Was able to repro with fastdebug build, hit an assertion while handling the crash. Not sure how much it helps finding the first crash but explains why we crash a second time. fastdebug version: java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b66) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b10-fastdebug, mixed mode)
04-12-2012
Possibly the same issue as in JDK-8003843 and JDK-8003841
03-12-2012
I'm now trying to reproduce this with a jdk8-fastdebug build. Also trying to reproduce it on a different Exalogic node to rule out that it's something wrong with the first one.
03-12-2012