Stress testing of the AsyncGetCallTrace() interface has exposed an
intermittent guarantee failure:
# guarantee(get_thread() == thread, "must be the same thread, quickly")
# Error ID : src/share/vm/runtime/threadLocalStorage.cp, 66
During JNI DetachCurrentThread(), the ThreadLocalStorage reference for
exiting JavaThread is set to NULL. However, an AsyncGetCallTrace() call
causes the cached thread info to be refreshed and we fail the guarantee.
Here is a partial stack trace:
 report_fatal(file_name = 0xfefd20ca "/work/ws/hotspot/main/baseline-exp/s
rc/share/vm/runtime/threadLocalStorage.cpp", line_no = 66, format = 0xfefd2119 "
must be the same thread, quickly", ...), line 139 in "debug.cpp"
 ThreadLocalStorage::set_thread(thread = (nil)), line 66 in "threadLocalSt
 Thread::delete_thread_and_TLS_current(this = 0x3e440), line 88 in "thread
 jni_DetachCurrentThread(vm = 0xff08a304), line 2501 in "jni.cpp"
 main(0xffbef208, 0xffbef2a4, 0xffbef2b4, 0x28800, 0x0, 0x0), at 0x11d48
The complete stack trace for the java_g crash is attached as threads.log.335.
In this particular failure, the VM crashed will trying to print out the
message about the guarantee failure, but that does not really obscure the
The failure reproduces with a less informative message with the java cmd:
# Error ID: 5448524541442C4F43414C33544F524147450E4350500042
The ErrorID maps to: threadLocalStorage.cpp, 66
Here is a snippet of the stack trace for the java cmd crash:
 report_fatal(0xfefdbc35, 0x42, 0xfefdbc84, 0xfeff4000, 0xfa17fef0, 0x0), a
 ThreadLocalStorage::set_thread(0x0, 0xffffffc4, 0xff013178, 0xffff8000, 0x
7f, 0x0), at 0xfec522a4
 _start(0xe3010, 0xfebf0c00, 0x0, 0x0, 0x0, 0x0), at 0xfecc5e4c
The complete stack trace for the java cmd crash is attached as threads.log.40.