Bug ID: JDK-4511812 merlin b81: Stress test jck12a012 crashes HotSpot VM in GC

JDK-4511812 : merlin b81: Stress test jck12a012 crashes HotSpot VM in GC

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: 1.4.0

Priority: P4
Status: Closed
Resolution: Cannot Reproduce
OS: solaris_8
CPU: sparc

Submitted: 2001-10-08
Updated: 2002-08-06
Resolved: 2002-08-06

Related Reports

Relates :

JDK-4463818 - Stress test jck12a012 crashes or hangs HotSpot VM

Description

The steps to reproduce this bug are described in bug 4463818 and a
summary is repeated below. That bug reported that a crash due to font code.
The cause of that crash has been identified and a fix is known (see
suggested fix for 4463818) but the stress test still could not complete
because it several times crashed apparently during GC. This was observed in
the 32-bit merlin b81 client VM running in mixed mode on Solaris 8 :-
Unexpected Signal : 10 occurred at PC=0xFE1DBA10


Function=JVM_GetCPFieldClassNameUTF+0x2DD4

the hotspot log is included as an attachment but on its own isn't enough
to suggest a GC problem but dbx shows this  backtrace :-

(/java/devtools/sparc/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) where     
current thread: t@4
=>[1] __sigprocmask(0x0, 0xfde80620, 0x0, 0x0, 0x0, 0x0), at 0xff379bf0
  [2] _resetsig(0xff37c510, 0x0, 0x0, 0xfde81d78, 0xff38e000, 0x0), at 0xff36e620
  [3] _sigon(0xfde81d78, 0xff395990, 0x6, 0xfde806f4, 0xfde81d78, 0xfde80738), at 0xff36dd10
  [4] _thrp_kill(0x0, 0x4, 0x6, 0xff38e000, 0x4, 0xff33a428), at 0xff370e84
  [5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff33a394, 0xfde80848), at 0xff2c9b08
  [6] abort(0xff336000, 0xfde80848, 0x0, 0xfffffff8, 0x4, 0xfde80869), at 0xff2b5124
  [7] os::abort(0x1, 0xfe39a352, 0xfde808e8, 0x0, 0xfe3fdfdc, 0xfe2e4e50), at 0xfe2e6210
  [8] os::handle_unexpected_exception(0x0, 0xa, 0xfe1dba10, 0xfde81608, 0xa, 0x0), at 0xfe2e4ec0
  [9] JVM_handle_solaris_signal(0xfe1dba10, 0xfde81608, 0xfde81350, 0x1, 0x0, 0x0), at 0xfe1e74a8
  [10] __sighndlr(0xa, 0xfde81608, 0xfde81350, 0xfe1e6c20, 0xfde81e10, 0xfde81e00), at 0xff37bd04
  [11] sigacthandler(0xa, 0xfde81d78, 0xfde81350, 0xff38e000, 0xfde81d78, 0xfde81608), at 0xff378508
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [12] SystemDictionary::always_strong_oops_do(0xfe3faf78, 0xfe3faf78, 0xf3eb0000, 0x0, 0x1, 0x2b7108), at 0xfe1dba10
  [13] GenCollectedHeap::process_strong_roots(0x47e80, 0x1, 0x0, 0x1, 0x2, 0xfe3faf78), at 0xfe1c3d4c
  [14] MarkSweep::mark_sweep_phase1(0x1, 0xfde818cc, 0x0, 0x3039a0, 0xfe1d9bc8, 0x0), at 0xfe1da528
  [15] MarkSweep::invoke_at_safepoint(0x5398, 0x4400, 0x4800, 0x4bc0, 0x4774, 0x0), at 0xfe1d9ccc
  [16] GenCollectedHeap::do_collection(0x0, 0x1, 0x0, 0xfe3e6000, 0xfe431494, 0x1), at 0xfe1c2da8
  [17] TwoGenerationCollectorPolicy::satisfy_failed_allocation(0x47e80, 0x26, 0x0, 0x0, 0xecb01298, 0xfde81ad8), at 0xfe1c2870
  [18] VM_GenCollectForAllocation::doit(0xecb01274, 0x4800, 0x241364, 0xfe3fc114, 0xfe3e6000, 0x0), at 0xfe1c2768
  [19] VM_Operation::evaluate(0xecb01274, 0x0, 0x2414dc, 0xfe42fbb0, 0xfe4262ac, 0x0), at 0xfe1a4d18
  [20] VMThread::evaluate_operation(0x63050, 0xecb01274, 0x0, 0x29590, 0xfe0fcc70, 0x0), at 0xfe1a4b98
  [21] VMThread::loop(0xfe40bf74, 0xfe3fc360, 0xfe3fc35c, 0x0, 0x0, 0x0), at 0xfe0fccdc
  [22] VMThread::run(0x63050, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe0fc7d8
  [23] _start(0x63050, 0xff38f6a0, 0x1, 0x1, 0xff38e000, 0x0), at 0xfe0fc6e8
(/java/devtools/sparc/SUNWspro/SC6.1/bin/../WS6U1/bin/sparcv9/dbx) 

The summary steps to reproduce are :-

get the test from

/net/sqesvr.eng/export/vsn/GammaBase/Bugs/4463818

set JAVA_HOME to a valid JDK
set JCK12a to JCK-1.2a (eg /import/javasoft/java/jck12)

Run sh doit1.sh $JDK12a $JAVA_HOME

Because of the nature of this test its always possible something else
will cause it to fail before you reach this bug, and in particular
you will need to ensure the suggested fix to 4463818 is in your build
else you'll crash because of that before this GC bug can manifest.

Comments

EVALUATION If I run the test in $GammaBase/Bugs/4463818 in Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84) with a recent HotSpot main/baseline JVM and the default heap size (64MB), I get lots of garbage collections, the heap fills up, several java.lang.OutOfMemoryError's are reported (presumably from the test code), the tests don't actually run (windows don't appear on my screen), and the test eventually falls over saying: # # HotSpot Virtual Machine Error, assertion failure # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (20011107.1052-main_baseline-compiler1-fastdebug-debug mixed mode) # # assert(handle != 0, "JNI handle should not be null") # # Error ID: /net/analemma/export/home/analemma/pbk/Workspaces/solaris_sparc/main_baseline/src/share/vm/runtime/jniHandles.hpp, 159 [ Patched ] # # Problematic Thread: prio=5 tid=0x3fa988 nid=0x20b runnable # but that's likely to be an actual bad JNI handle being passed to the JVM. I'm running a fastdebug build, so I get assertion checking. If I run with the heap increased to not get OutOfMemoryErrors (-Xmx80m), I get a bunch of other errors and a summary of Stress test failed: class jck12a012 32 of 575 primary tests have failed. 5 of 575 primary tests have ignored due to lack of resources. >>> All registered JCK tests finished If I run with -Xmx96m I get a few failures that look like internal confusion in the tests, e.g., Start: class javasoft.sqe.tests.api.java.awt.Color.getColor44Tests Failed. tests: 3; passed: 2; failed: 1; first test case failure: 0:0 ---------------------------------------------------------------- AssertionTest Report ---------------------------------------------------------------- Method Name : public static java.awt.Color java.awt.Color.getColor(java.lang.String) Class Name : class java.awt.Color ---------------------------------------------------------------- -------------------------------------------------------------- Index of factory objects : 0:0 Exception Raised during Testing : java.lang.IllegalArgumentException: name can't be empty at java.security.BasicPermission.init(BasicPermission.java:79) at java.security.BasicPermission.<init>(BasicPermission.java:129) at java.util.PropertyPermission.<init>(PropertyPermission.java:138) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) at javasoft.sqe.tests.api.java.awt.Color.getColor44Tests.predictExceptionSet(getColor44Tests.java:101) at javasoft.sqe.javatest.lib.apitest.AssertionTest.runTest(AssertionTest.java:338) at javasoft.sqe.javatest.lib.apitest.GridGenerator.executeTestCase(GridGenerator.java:121) at javasoft.sqe.javatest.lib.apitest.GridGenerator.iterate(GridGenerator.java:96) at javasoft.sqe.javatest.lib.apitest.GridGenerator.run(GridGenerator.java:55) at javasoft.sqe.javatest.lib.apitest.AssertionTest.run(AssertionTest.java:91) at javasoft.sqe.stresstest.StressTest$TestThread.run(StressTest.java:825) Test Status : java.lang.IllegalArgumentException: name can't be empty raised. -------------------------------------------------------------- -------------------------------------------------------------------- Overall AssertionTest Result Summary -------------------------------------------------------------------- Overall Test Status : Failed Total Number of Tests : 3 Total Tests Passed : 2 Total Tests Failed : 1 -------------------------------------------------------------------- which I can't really interpret. Then the test seems to hang. If I run it with -Xcheck:jni (suspicion aroused by the assertion failure with 64MB heap), I fail pretty quickly with FATAL ERROR in native method: Calling other JNI functions in the scope of Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical at sun.awt.font.NativeFontWrapper.registerFonts(Native Method) - locked <f5699eb0> (a java.lang.Class) at sun.awt.X11GraphicsEnvironment.registerFontFile(X11GraphicsEnvironment.java:592) at sun.awt.X11GraphicsEnvironment.registerFontPropertiesFonts(X11GraphicsEnvironment.java:540) at sun.java2d.SunGraphicsEnvironment.initTerminalNames(SunGraphicsEnvironment.java:992) at sun.java2d.SunGraphicsEnvironment.initCompositeFonts(SunGraphicsEnvironment.java:780) at sun.java2d.SunGraphicsEnvironment.access$100(SunGraphicsEnvironment.java:60) at sun.java2d.SunGraphicsEnvironment$1.run(SunGraphicsEnvironment.java:164) at java.security.AccessController.doPrivileged(Native Method) at sun.java2d.SunGraphicsEnvironment.<init>(SunGraphicsEnvironment.java:89) at sun.awt.X11GraphicsEnvironment.<init>(X11GraphicsEnvironment.java:153) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:42) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:30) at java.lang.reflect.Constructor.newInstance(Constructor.java:277) at java.lang.Class.newInstance0(Class.java:301) at java.lang.Class.newInstance(Class.java:254) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:65) - locked <f5589eb0> (a java.lang.Class) at java.awt.Window.init(Window.java:211) at java.awt.Window.<init>(Window.java:255) at java.awt.Frame.<init>(Frame.java:401) at java.awt.Frame.<init>(Frame.java:366) at javasoft.sqe.tests.api.java.awt.Event.ContainerEvent.ContainerEventTests.<init>(ContainerEventTests.java:35) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:42) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:30) at java.lang.reflect.Constructor.newInstance(Constructor.java:277) at java.lang.Class.newInstance0(Class.java:301) at java.lang.Class.newInstance(Class.java:254) at javasoft.sqe.stresstest.StressTest.registerTest(StressTest.java:568) at javasoft.sqe.stresstest.StressTest.registerTest(StressTest.java:646) at jck12a012.registerStressGroup(jck12a012.java:189) at javasoft.sqe.stresstest.StressTest.run(StressTest.java:454) at jck12a012.main(jck12a012.java:39) You aren't allowed to call a JNI method while your thread is in a "Critical" section, because JNI calls might block and you aren't allowed to block in a critical section or you'll deadlock the JVM. Someone has to convince me that this is a valid test before I'll look at it further. There's the JNI bogosity, then there's the question of whether the heap is large enough to run the test, and how the tests react to lack of resources if the heap isn't large enough. ###@###.### 2001-11-07 ###@###.### 2002-08-05 The crash reported in this tests is not reproducible with the current 1.4.1. Clarification was requested but was not forthcoming.

07-11-2001