JDK-6855551 : java -Xrunhprof crashes when running with classes compiled with targed=7
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-06-27
  • Updated: 2012-02-02
  • Resolved: 2009-07-17
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 7 Other
7 b66Fixed OpenJDK6Fixed
Related Reports
Relates :  
Description
Starting from jdk7b62 "java -Xrunhprof" crashes with ACCESS_VIOLATION on windows and SIGSEGV on linux/solaris when running with classes compiled with targed=7. 
The crash occurs on all platforms.

The crash started to appear from jdk7b62 where default javac options -source and -target 
were changed from 6 to 7, see 6827026 "Change javac source and target default to 7" 
for more details.

Steps to reproduce:

> JDK7B62_HOME/bin/javac Hello.java
> JDK7B62_HOME/bin/java -Xrunhprof:file=hprof.out Hello
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d3b1057, pid=6300, tid=676
#
# JRE version: 7.0-b62
# Java VM: Java HotSpot(TM) Client VM (16.0-b04 mixed mode windows-x86 )
# Problematic frame:
# C  [java_crw_demo.dll+0x1057]

No crash in case java file is compiled with "-source 6 -target 6":
> JDK7B62_HOME/bin/javac -source 6 -target 6 Hello.java
> JDK7B62_HOME/bin/java -Xrunhprof:file=hprof.out Hello
Dumping Java heap ... allocation sites ... done.

Comments
EVALUATION http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/13fbbc4df814
08-12-2009

EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3a08f8c3c86
08-07-2009

EVALUATION It appears that on Windows, all builds have the assert checking enabled. This appears to be due to the fact that NDEBUG is not defined on the compile line for Windows. The fix for 6855180 will prevent the assert error and the crash, so they are very much related, but there is more to the story. But there are multiple issues here. The java_crw_demo logic is calling it's error handler with a "ci" or class image pointer that might not be defined yet, so these early asserts on the initial reads of the classfile will trigger segvs or exceptions in native code. So I see multiple issues: 1. Linux and Windows optimized compilations should add -DNDEBUG to their compile lines (separate bug will be filed). This bug has been there since day one, and may impact more than just this code, none of the Linux or Windows native code is built with -DNDEBUG, which may change the performance or behavior of the 'product' bits. Defining NDEBUG typically turns assert() statements invisible, whether everyone wants that in the product or optimized bits might be an issue, but it seems to me that assert() is a debugging thing, not a product thing. 2. The error function in java_crw_demo should not dereference pointers that might not be defined yet. This bug has been there since day one. Thanks go to the sqe team for filing this bug.
07-07-2009

EVALUATION Could be a duplicate of 6855180. Not positive, thought 6855180 would only impact a debug build because it was mostly an assert check being fixed. This may need more investigation.
30-06-2009