United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6354181 nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111"
JDK-6354181 : nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111"

Details
Type:
Bug
Submit Date:
2005-11-22
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
generic,linux_2.6
Sub-Component:
compiler
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:
hs21 (b03)

Related Reports
Backport:
Duplicate:
Relates:

Sub Tasks

Description
nsk.logging.stress.threads.scmhml001 fails assertion on Linux starting at
least from jdk6.0b60-debug.

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error
(/BUILD_AREA/jdk6.0/hotspot/src/share/vm/oops/instanceKlass.cpp, 111),
pid=6464, tid=1620585392
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-rc-fastdebug-b61-debug compiled
mode)
#
# Error: assert(is_loaded(),"must be loaded")
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Full hs_err_pid6464.log, the test and test results are located here:
/home/ep155969/sqe_vm/testrun/scmhml001/ep155969.Linux.x86/scmhml001/

This bug is not often reproduced. So, to reproduce it run
'reproduce_bug.sh' which will try to run the test till it will be failed.

To reproduce the bug use any Linux SuSe-9.? machine
(I was able to reproduce ot on raveena.sfbay)
nsk/logging/stress/threads/mymhml001 also fails with same error.

                                    

Comments
EVALUATION

The is_loaded method in the ci doesn't mean is the init_state >= loaded, it means do we have a real perm object in hand.  We're somehow getting a hold of the instanceKlass while it's still in the allocated state but we consider it loaded because we've got a hold of it.  

<ciInstanceKlass name=java/util/logging/LogRecord loader=0x0 loaded=true initialized=false finalized=false subklass=false size=72 init_state=1 flags=public,super ident=881 PERM address=0xa0318c10># To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/instanceKlass.cpp:227
==============================================================================
Unexpected Error
------------------------------------------------------------------------------
Internal Error at instanceKlass.cpp:227, pid=26515, tid=2669394800
assert(init_state >= loaded) failed: must be loaded

Do you want to debug the problem?

To debug, run 'gdb /proc/26515/exe 26515'; then switch to thread -1625572496 (0x9f1bbb70)
Enter 'yes' to launch gdb automatically (PATH must include gdb)
Otherwise, press RETURN to abort...
==============================================================================
                                     
2011-01-25
EVALUATION

6354181: nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111"
Reviewed-by: jrose, acorn

Looking up classes through the loader constraints allows classes which
aren't fully loaded to leak into the compiler.  This would be ok
except that ciObject has a notion of is_loaded that it different than
instanceKlass::is_loaded which makes it impossible to distinguish
these states.  Since no one should really be able to lookup classes
which aren't at least load the fix is to tighten up the interfaces in
SystemDictionary to weed these out.  I also added asserts in the CI
that would have identified the issue earlier.  It also seems like the
CI should be holding the Compile_lock during these lookups to ensure
greater consistency in the class hierarchy.  Tested with failing test
from report and runthese.
                                     
2011-02-01
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4f26f535a225
                                     
2011-02-01



Hardware and Software, Engineered to Work Together