JDK-8029873 : compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2013-12-10
  • Updated: 2014-07-29
  • Resolved: 2014-01-08
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.
JDK 8 JDK 9
8u20Fixed 9 b02Fixed
Description
Comp_Baseline nightly from 2013-12-06 shows crashes (SIGSEGV) in compiled code for the following test: "compiler/uncommontrap/TestStackBangRbp.java".

The crash reproduces deterministically on 64-bit Linux systems. The crash seems to 
reproduce only with ' -XX:+DeoptimizeALot '

ILW=HLW

High      .. Crash
Low       .. Seems to require -XX:+DeOptimizeALot to be triggered
Medium .. Increase the stack size, disable the compilation of failing method

hs_err file is attached
Comments
Release team: Approved for deferral.
12-12-2013
SQE is ok to defer to 8u20
12-12-2013
ILW=HLW=>P3 Impact: Crash hence high Likelihood: This happens with the stress flag -XX:+DeoptimizeALot which does expose real issues but not something that would necessarily happen frequently with product. Workaround: Increase the stack size (-Xss) Evaluation: class loading from uncommon trap runtime calls java code which causes a stack overflow right before the return to the runtime. The stack is no longer guarded when we return to the uncommon trap blob. The stack bang of the uncommon trap causes a stack overflow but because the stack is not guarded, the VM crashes. Target release for deferral: 8u20. Risk Assessment: Not a critical fix since we've only seen it with DeoptimizeALot, the issue is still real just less likely to happen with a normal run. The likelihood is low and you can workaround it easily by increasing the stack size.
11-12-2013