JDK-6216426 : JCK1.5a: api/java/awt/interactive/DnDComponentTest crashs, linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-01-12
  • Updated: 2010-04-02
  • Resolved: 2005-07-01
Related Reports
Duplicate :  
Description
JCK            : jck1.5a
J2SE           : FAIL - tiger, mustang 
Platform[s]    : FAIL - turbo 8 +, cinnabar, RHAS3
                 PASS - solaris, windows
switch/Mode    : FAIL - -client -Xcomp 
                 PASS - default, -client, -server
                 
JCK test owner : http://javaweb.sfbay/jcce/tcks/jck/docs/others/owners.jto

Failing Tests   : 
api/java/awt/interactive/DnDComponentTest

Test source location:
=====================
/net/jtgb4u4c/export/sail1/testarea/jck1.5a.b01/JCK-runtime-15a/tests/api/java_awt/interactive/DnDComponentTest.java

jtr file location:
==================
attached

How to reproduce:
====================
NOTE* 
1) run the script below with -Xcomp flag.  
   The test crashes trying to drag&drop.  
2) run the script without the -Xcomp flag. The test does not crash.
3) rerun the script with -Xcomp flag, and test does not crash anymore.
4) reboot the system and rerun the script with -Xcomp flag.  It crashes again.

-------script START---------------------
#!/bin/sh

#Paths in Java Software:
JDK="/export/jdk/b16/linux-i586/jdk1.6.0"
JCK="/net/jtgb4u4c.sfbay/export/sail1/testarea/jck1.5a.b01/JCK-runtime-15a"
CLASSPATH="$JCK/classes:$JCK/lib/javatest.jar"

TEST="javasoft.sqe.tests.api.java.awt.interactive.DnDComponentTest -platform.robotAvailable false -TestCaseID ALL"

echo `cat $JCK/build.txt | grep JCK_VERSION` `cat $JCK/build.txt | grep JCK_BUILD`

$JDK/bin/java -client -Xcomp -showversion -cp $CLASSPATH $TEST
--------script END----------------------

Test output:
=============
attached hs_err_pid10977.log
[root@lunar b16]# sh turbo2.sh
JCK_VERSION=1.5a JCK_BUILD_ID=b01
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b16)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b16, compiled mode, sharing)

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x401ce538, pid=10977, tid=5126
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b16 compiled mode, sharing)
# Problematic frame:
# V  [libjvm.so+0x55538]
#
# An error report file with more information is saved as hs_err_pid10977.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
turbo2.sh: line 16: 10977 Aborted                 
$JDK/bin/java -client -Xcomp -showversion -cp $CLASSPATH $TEST


Specific Machine Info:
=====================
[root@lunar root]# uname -a
Linux lunar 2.4.18-1smp #1 SMP Mon Apr 29 02:19:46 JST 2002 i686 unknown
###@###.### 2005-1-12 00:58:03 GMT
###@###.### 2005-1-12 00:59:17 GMT

Comments
EVALUATION The behavior described by the submitter is definitely reproducible. With a RHAS 3.0 machine after a clean reboot, running the test case with Mustang promoted build 16 yields a crash. If the test is rerun, at some point it will begin to succeed, after which it will continue to pass. Running with Mustang build 41 always works, even after a clean reboot. I tried dropping a build 41 VM into a build 16 JDK which also worked after a clean reboot. This doesn't necessarily mean that the bug is in the VM, though, because it's possible that the native code for the AWT or another library was buggy back in build 16 and that the build 41 VM is more resilient to those kinds of programming errors. I tried to use gdb and -XX:+ShowMessageBoxOnError to get more information about what the failing thread was doing. However gdb can't walk the stack above the signal handler frame. It also can't disassemble the (apparently generated code) program counter above the signal handler. The X server also locks up when -XX:+ShowMessageBoxOnError is specified. Because this bug is no longer reproducible in build 41 and because investigating the root cause of the build 16 crash will probably take a significant amount of time because the debugger is not useful, I'm closing this bug as "not reproducible". Please reopen it or open a new bug if a similar failure reoccurs. ###@###.### 2005-06-24 00:09:13 GMT Upon further investigation of the hs_err log files from the crashes on the machine as well as the one attached to this bug report (which I missed the first time through), it's pretty clear that C1 is crashing during compilation of the method sun.awt.X11.MotifDnDConstants.putTargetListTable(J[[J)V (450 bytes) which is what is taking down the JVM. Given that the b41 VM runs fine in the b16 JDK, this bug in C1 must have been fixed since then. ###@###.### 2005-06-24 00:36:17 GMT Decoding the stack trace indicates that it's dying inside load_byte_item with a SEGV which is consistent with 6237349. ###@###.### 2005-07-01 19:16:30 GMT
24-06-2005