JDK-4996629 : SWAT: Java2D demo throws core dump in win2003 AMD
  • Type: Bug
  • Component: client-libs
  • Sub-Component: demo
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2003
  • CPU: x86
  • Submitted: 2004-02-18
  • Updated: 2014-03-14
  • Resolved: 2014-03-14
Related Reports
Relates :  
JDK-5009695 - AMD64: Java2Demo crashes with java_g and -XX:+FullGCALot
Relates :  
JDK-5040096 - Vtest/Vmark fail after 6 hrs run on windows2003 AMD 64bits with C2 flag
Description
Running the Java2D demo for SWAT test, I found the core dump is genereated in win2003 AMD machines.

Host names: Applebee, Bela

Attached is the core dump files:
Applebee b39: hs_err_pid7924.log
Bela b39: hs_err_pid2108.log
bela b37: hs_err_pid2376.log

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000077f7d9d4, pid=2108, tid=2252
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0-beta2-b39 mixed mode)
# Problematic frame:
# C  [ntdll.dll+0x7d9d4]
#

STEP TO REPRODUCE:
==================
1. install b39 bundle in the win2003 AMD machine
2. invoke Java2D.jar demo
3. let the "run windows" run for 10 times

###@###.### 2004-02-18
===========================

Using -Xbatch mode on "bela", it's fairly eazy to reproduce the bug.  2 core dumps are reproduced this morning in the SWAT testing.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000077f7d9d4, pid=2552, tid=2604
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0-beta2-b41 mixed mode)
# Problematic frame:
# C  [ntdll.dll+0x7d9d4]
#

Attached the core dump file: hs_err_pid2552.log

-Xcomp throws "java.lang.NullPointerException" many many times.

###@###.### 2004-03-03
Comments
EVALUATION I tried running Java2Demo on WinXP-AMD64 and I don't see any VM crash though there are many exceptions because of the threading issues. Threading issues are tracked under separate bug ids (4965892, 4902189, 4971236) and we are working on providing a workaround in mustang for the threading issue. We will consider a complete revamp of the entire threading code in Dolphin and hence I am committing this to Dolphin and leaving it open for now.
26-07-2005
EVALUATION I let Java2Demo run all night on an AMD64 machine running Win2003, and not one crash. This was with B39 ###@###.### 2004-02-25 Out of the four runs, Java2Demo crashed once in a compiled frame and one in an interpreter frame. Probably not a C2 bug, but handing this to runtime and a AMD64 expert. ###@###.### 2004-02-26 I ran this test all night on my Windows AMD64 Server 2003 system and did not see a single crash. It is my understanding that this test crashed while another (jndi) test was running. Please try to reproduce this failure independent of this other test. ###@###.### 2004-03-03 I found a problem in the VM where calling native methods with a large number of arguments can cause corruption or a SEGV see bugid 5009695. This fix has been putback to B43. Please retest this problem with B43 to see if it is fixed. I have also built an interum VM with this fix. It is located at /net/wabi.east/scratch2/winamd64/jvm.* ###@###.### 2004-03-09 The bug does still occur aft erthe fix to bugid 5009695 was added. ###@###.### 2004-03-31 I worked on this bug for several days attempting to find the root cause. I have only been able to reproduce the crash twice and each time the crash was in the Microsoft C Runtime library MSVCRT.DLL at the memory free() routine. We are calling the free() routine from the native fontmanager library or the dcpr native library with either a corrupt pointer or the C heap has been corrupted. I built an optimized debug VM and tried several of our stress flags in the hopes that it woul dmake the problem more reproducable. These include -Xcomp, -XX:+DeoptimizeRandom, -XX:+SafepointALot, -XX:+FullGCALot. These flags had no effect on the reproducabiulity of the problem. The fact that the Java2Demo is a very unstable application is inhibiting my ability to diagnose this problem. Most of the time I get either a Null Pointer Exception or Array Index out of Bounds exception and the application will hang. This problem is documented in bugid 4902189. In addition, it is somewhat likely that these exceptions are creating the bug that is reported here. Since the crash is occuring in the native graphics library and the Java2Demo is unstable, I am going to pass this bug back to the Java2D team. Once the application can be cleanly run, we can see if this bug is still occuring. ###@###.### 2004-03-31 Indeed, the bug is very hard to reproduce with Java2Demo throwing exceptions and hanging because of that (although I don't think that exceptions would cause the crash). We should fix the demo first. I've attached a typical log with exceptions. I saw a crash once, but I believe it's a different bug: it looks like we crash when the screen saver is started. I haven't been able to reproduce the crash once I've disabled the screen saver. Also, since the bug is so hard to reproduce and specific to windows-amd64, I'm lovering the priority to P3. ###@###.### 2004-04-09 As suggested by Dmitri and Jeannette earlier, we need to refine the threading code in the demo first. ###@###.### 2004-04-09 I found a bug recently on Windows AMD64 that might account for the crash I saw in MSVCRT.DLL in the free memory library call. This bug 5040096 will be fixed in tiger_rc. This bug should be retested once this fix is integrated in a release. ###@###.### 2004-06-14
14-06-2004