United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4995019 : 1.4.2_03 client JIT compiler optimization causing JVM to core

Details
Type:
Bug
Submit Date:
2004-02-14
Status:
Closed
Updated Date:
2004-06-11
Project Name:
JDK
Resolved Date:
2004-05-10
Component:
hotspot
OS:
linux_suse_sles_8.2
Sub-Component:
compiler
CPU:
x86
Priority:
P1
Resolution:
Fixed
Affected Versions:
1.4.2_03
Fixed Versions:
1.4.2_05 (05)

Related Reports
Relates:

Sub Tasks

Description
The client JIT compiler optmization of sun.misc methods results in a client JVM segv. This was discovered on Linux Hotspot 1.4.2_03 client JVM.
###@###.### 2004-02-14

                                    

Comments
WORK AROUND

Create .hotspot_compiler file with the entries:
ClassCopierOrdinaryImpl$13.copy
...
ClassCopierOrdinaryImpl$20.copy
in it force client JIT compiler to not optimize these methods.
###@###.### 2004-02-14
###@###.### 2004-02-14
                                     
2004-02-14
EVALUATION

Some people from the CORBA team and I have spent some time trying to
reproduce this bug. Several configurations have been tried, including
Solaris/SPARC, Solaris/x86, and Linux/x86. On the suggestion of
###@###.###, both debug and product JVMs have been tested
on both Solaris platforms (copying libjvm_g.so onto libjvm.so doesn't
seem to work on Linux). A .hotspotrc file was placed into
build/rename/ee/test/make/ in order to affect the command line
arguments for the subordinate VM (where the suspect classes are being
loaded) and the client.out.txt and client.err.txt files in
build/rename/ee/test/make/gen/corba/copyobject were examined, but no
crashes were observed. Flags supplied were equivalent to
-verbose:class -XX:+PrintCompilation -Xcomp. A run with
-XX:+FullGCALot -XX:FullGCALotInterval=1000 was attempted but this
seemed to time out while running rmic in preparation for running the
actual test.

Upon discussion with the CORBA team it appears that to date the
reported crash has only been observed on one machine, the home PC of
###@###.### . This might indicate a hardware or
configuration problem although I consider that unlikely. More probably
it is the case with his memory configuration that a safepoint and GC
are being taken at a PC where we have an incorrect oop map. In order
to confirm this we would need to supply more stress options to the
subordinate VM and increase the test's timeout interval.

The CORBA team will try to get more information on how to reproduce
this bug either later or tomorrow and investigation will continue.

###@###.### 2004-02-17


###@###.### provided a HotSpot build that would halt the VM in the
problem case of a non-empty expression stack at a backward branch and this was
triggered during the javac compile of some of the stub classes even before the
test case itself ran. I'm in the process of modifying these changes so they
don't crash the VM so we can see all of the places they occur.

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


I reran the test after removing the guarantee and found that it triggered
several times while running the javac process that is part of the setup for
the test, but not while running the test itself. This indicates that the crash
is not due to a known problem in the client compiler.

Marking the bug as incomplete until we can get more information about how to
reproduce it. Information about how to increase the test's various timeouts
would be helpful as we could then run the VM with more stress options.

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


Bug has been diagnosed; see comments.

###@###.### 2004-03-12


Bug fix has been submitted to CTE for inclusion in the 1.4.2_05 update release.

###@###.### 2004-03-17
                                     
2004-03-12
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_05
generic

FIXED IN:
1.4.2_05

INTEGRATED IN:
1.4.2_05

VERIFIED IN:
1.4.2_05


                                     
2004-06-18



Hardware and Software, Engineered to Work Together