JDK-4698522 : Jython script crashes JVM on 1.4.1_beta_b14
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-06-06
  • Updated: 2002-07-23
  • Resolved: 2002-06-20
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.
Other
1.4.1 rcFixed
Related Reports
Relates :  
Description
Python script used by BigApps testing team crashes JVM -- apparently in
multiple place -- when running Jython 2.1 interpreter atop JRE
in 1.4.1_beta_b14.  See attachments for some snapshots taken at
postmortem.

Chris Vick has looked at this most extensively.
[cnc - Actually, Cliff Click looked at it extensively.  See eval.]

Python script that precipitated crash is attached "AwtAbuse2.py".
Brief instructions on how to use are in attached file
"testCase.txt".


I have Jython interpreter and Python code used to cause this crash.

Fred Clegg
x17397
###@###.###

2002-06-07

Starting Jython interpreter used for this test on RedHat Linux 7.2
also causes VM to fail.  See attached files:
   jyfail.txt            screen output
   hs_err_pid4791.log    error log file produced
   jythons.sh            script used to launch Jython interpreter

Fred Clegg
x17397
###@###.###

###@###.### 2002-06-10

At the request of Peter Kessler, I have rerun my Linux-based test
using the  -client  option.  VM promptly dies in this case, as well.
See attached files:
   jyfail2.txt           screen output
   hs_err_pid13050.log   error log file produced
   jythonclient.sh       script used to launch Jython interpreter with -client

###@###.### 2002-06-11


I reran my Windows 2000-based test using  -client  rather than  -server
as previously.  VM promptly crashed again, even before start-up of Jython 
interpreter had been completed.

At the suggestion of Harshad Vilekar and Kevin Smith, I have red-tagged this
bug and also changed it to P2.

See attached files:
   fail2612regs.txt           CPU registers at time of crash
   fail2612src.txt            Source code surrounding crash site
   fail2612stk.txt            Stack trace back from crash site

###@###.### 2002-06-12

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc
14-06-2004

PUBLIC COMMENTS Jython interpreter crashes JVM on 1.4.1_beta_b14
10-06-2004

EVALUATION This appears to be a compiler2 issue as the code noted and not a runtime specific issue. ###@###.### 2002-06-10 Installed and tested on sparc solaris 8 and it reproduces there as well as original platform mentioned in the bug report as win2k.. All I needed to do is add -server and it will crash eventually. ###@###.### 2002-06-10 I attached my hotspot.log file for -server crash... This crash is for a Solaris 8 U80 machine. I have not been able to get client to crash. ###@###.### 2002-06-11 I camped out in Fred's office and looked at this a bit. Turns out that with a command line that had a 'CompileOnly=.foo' exactly 1 method compiled and then we crashed. No idea what the method name was, I was hoping Fred would include the name in the bug report. Said method was very short and exactly compiled only the most general form of the subtype check (unknown sub vs unknown super). This code is only generated rarely, hence I'd believe a bug lurks in it. Failure would likely be an illegal cast of a Foo as a Bar (when it's not), and then doing bad Bar-like things to a Foo. This will trash the help and likely show up at the next GC. ###@###.### 2002-06-11 Method is '__toJava__' with various classes. Inlines reflective intrinsic Class.isInstance(). There's a C2 bug, where we incorrectly elide the null check needed to check for primitive types. I.e., if you ask "is this object an instance of the Java Class for 'int'?" we take an unexpected null pointer exception & die. Fix is to properly tell the optimizer that loading the HotSpot klass metadata object from a Java Class mirror can sometimes report a null. I did _not_ fix any C1 or interpreter bug. ###@###.### 2002-06-12 Found a 2nd C2 bug, where the inlined Class.getClassModifiers failed to put a partially optimized Region on the IGVN worklist for later cleanup. ###@###.### 2002-06-13
12-06-2002