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
xxxxx@xxxxx , 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
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
xxxxx@xxxxx . 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.
xxxxx@xxxxx 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.
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.
Bug has been diagnosed; see comments.
Bug fix has been submitted to CTE for inclusion in the 1.4.2_05 update release.