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.
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
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

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)

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.

Why is there no "Resolved in build" information for this bug? Why does this issue seem to have so many bugs associated with it?


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.

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)

Possibly the same issue as in JDK-8003843 and JDK-8003841

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.