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.
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
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
18-06-2004
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
12-03-2004
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