###@###.### 2003-02-24

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:

  [29] 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"
  [30] ThreadLocalStorage::set_thread(thread = (nil)), line 66 in "threadLocalSt
orage.cpp"
  [31] Thread::delete_thread_and_TLS_current(this = 0x3e440), line 88 in "thread
.cpp"
  [32] jni_DetachCurrentThread(vm = 0xff08a304), line 2501 in "jni.cpp"
  [33] 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
original failure.

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:

  [6] report_fatal(0xfefdbc35, 0x42, 0xfefdbc84, 0xfeff4000, 0xfa17fef0, 0x0), a
t 0xfee34a7c
  [7] ThreadLocalStorage::set_thread(0x0, 0xffffffc4, 0xff013178, 0xffff8000, 0x
7f, 0x0), at 0xfec522a4
  [8] _start(0xe3010, 0xfebf0c00, 0x0, 0x0, 0x0, 0x0), at 0xfecc5e4c

The complete stack trace for the java cmd crash is attached as threads.log.40.