JDK-6239336 : JVM internal error/EXCEPTION_ACCESS_VIOLATION, possibly memory related?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-03-11
  • Updated: 2011-02-16
  • Resolved: 2005-05-27
Related Reports
Duplicate :  
JDK-6215242 - ShouldNotReachHere() failure at hotspot/src/cpu/i486/vm/c1_FrameMap_i486.cpp, 92
Relates :  
JDK-4738111 - java crashes or hangs when display mode changes on Matrox g400 (Windows only)
Relates :  
JDK-6231558 - JVM outputs exceptions or crash with a program using Big interger in 1.4.2_08b2
Relates :  
JDK-4917709 - SEGV in MapLoops test
Description
FULL PRODUCT VERSION :
java version "1.4.2_06"
java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows XP SP1

A DESCRIPTION OF THE PROBLEM :
http://web.mit.edu/charvak/Public/Java/javaerror.GIF shows what's left on the command prompt when appletviewer crashes.  I wrote the applet located at http://web.mit.edu/charvak/Public/Java/ and it runs on Mac OS9 and MIT's UNIX-based Athena system, but won't work on Windows XP.

Specifically, the program performs as expected for very small inputs like A1=2 and D1=2.  However, it only runs a few times and crashes eventually.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open http://web.mit.edu/charvak/Public/Java/AA.html.  Hit clear and then type 2's in the boxes that contained A1 and D1.  Hit "calculate probs" and the program will run.  Repeat that a total of 8 times and the applet will crash.  In theory, it should perform the same every time.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I was expecting the applet to run the same every time I hit "calculate probs" and with numbers on the order of 10 as inputs.
ACTUAL -
The applet seems to die after performing a certain amount of computation.  It can take two 1's and process them about 40 times.  Two 2's will kill it after 8 tries.  Large enough numbers kill it immediately.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
http://web.mit.edu/charvak/Public/Java/javaerror.GIF

----------------------AND-----------------

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x0
Function name=(N/A)
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.



Current Java thread:
	at sun.awt.Win32GraphicsDevice.getDefaultPixID(Native Method)
	at sun.awt.Win32GraphicsDevice.displayModeChanged(Unknown Source)
	at sun.awt.windows.WToolkit.displayChange(Unknown Source)
	at sun.awt.windows.WToolkit.eventLoop(Native Method)
	at sun.awt.windows.WToolkit.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

Attached seperately

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I have no workaround besides running on a different OS.
###@###.### 2005-03-11 09:45:12 GMT
Comments
EVALUATION Based on the evaluation, the crash is happened on appletviewer too, so this is not a plugin bug, but a AWT or Swing issue, will reassign it to those group. ###@###.### 2005-03-11 21:40:06 GMT May be related to 4738111. There are similar call from Toolkit.displayChange() for getDefaultPixID(screen) described. I wonder if this is a regression of that fix? It also seems to be already fixed in JDK1.5.0 since it's not reproducible anymore. Actually I'm not able to see how this applet may crash possibly because of different video card on my PC. I've tried JDKs from JDK1.4.0 till current Mustang build. ###@###.### 2005-05-25 12:15:58 GMT This is confusing. The stack trace in the bugreport shows the crash in getDefaultPixelID() called from displayChange(). But this is not possible in any version of jdk1.4.2 since the method was renamed to displayChanged(), and the getDefaultPixelID() is not called from displayChanged because of the fix for 4738111 (which was ported to 1.4.1_02 as well). So I'm going to assume that the stack trace was from some earlier jdk, where 4738111 was not yet fixed. As for the crashes that can be reproduced, they actually occure in the vm, not in the libraries. And I've verified that it doesn't die if run with -Xint. So I'm reassigning the bug to the client compiler team. ###@###.### 2005-05-26 23:06:48 GMT This is a dup of 6215242 which has a long and sordid history back to 4917709. This is fixed in 1.4.2_08 and doesn't effect 1.5.0 so I'd recommend updating to 08. You could also use 1.4.2_05 or earlier though those all have 4917709 which is somewhat harder to hit. Sorry. ###@###.### 2005-05-27 00:17:11 GMT
11-03-2005