JDK-4456481 : MethodEntryEvent.toString() after Thread.exit() causes assertion failure
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2001-05-09
  • Updated: 2005-03-03
  • Resolved: 2005-03-03
Related Reports
Relates :  
Description
It appears that MethodEntryEvents are generated for method entries after the
debuggee thread exits.  If MethodEntryEvent.toString() is called on
one of these events, a segv (or assertion failure) occurs.  The FE tries
to get the name of the exitted thread.

Here is the testcase:

/net/jano/export/disk20/serviceability/ws/regressionTestsInWaiting/MethodEntryAfterThreadDeath.java

And here is the stack:

Current function is threadInfo
 1181       HANDLE_ERROR(jvmdi->GetThreadInfo(thread, info));
t@8 l@7:1 pathmap /export/disk05 /net/jano/export/disk05
t@8 l@7:2 where
current thread: t@8
  [1] __sigprocmask(0x0, 0xfb1808e0, 0x0, 0xffffffff, 0xffffffff, 0x0), at 0xff379e54
  [2] _resetsig(0xff38cae4, 0x0, 0xfb181dc0, 0x0, 0x0, 0xfb181e40), at 0xff36f3ec
  [3] _sigon(0xff3944d8, 0xff3943d8, 0xfb181e38, 0xfb1809b4, 0x6, 0xff2cdf6c), at 0xff36eb10
  [4] _thrp_kill(0x0, 0x8, 0x6, 0xff38cae4, 0xfb181dc0, 0xff393d54), at 0xff371a20
  [5] abort(0xff3359c8, 0xfb180ab0, 0x0, 0xfffffff8, 0x0, 0xfb180ad1), at 0xff2b95a8
  [6] os::abort(dump_core = 1), line 1029 in "os_solaris.cpp"
  [7] report_error(is_vm_internal_error = 1, file_name = 0xfe26ec70 "/export/disk05/hotspot/users/mchung/merlin_service/src/share/vm/runtime/handles.hpp", line_no = 67, title = 0xfe203ec8 "assertion failure", format = 0xfe203edc "assert(%s, "%s")", ...), line 339 in "debug.cpp"
  [8] report_assertion_failure(code_str = 0xfe26ec60 "_handle != 0", file_name = 0xfe26ec70 "/export/disk05/hotspot/users/mchung/merlin_service/src/share/vm/runtime/handles.hpp", line_no = 67, message = 0xfe26ecc4 "resolving NULL handle"), line 148 in "debug.cpp"
  [9] Handle::non_null_obj(this = 0xfb181710), line 67 in "handles.hpp"
  [10] typeArrayHandle::non_null_obj(this = 0xfb181710), line 165 in "handles.hpp"
  [11] typeArrayHandle::operator->(this = 0xfb181710), line 165 in "handles.hpp"
  [12] GetThreadInfo(jni_thread = 0x9014c, infoPtr = 0xfb18184c), line 2285 in "jvmdi.cpp"
=>[13] threadInfo(thread = 0x9014c, info = 0xfb18184c), line 1181 in "util.c"
  [14] name(in = 0xfb181a44, out = 0xfb1818ec), line 36 in "ThreadReferenceImpl.c"
  [15] debugLoop_run(), line 117 in "debugLoop.c"
  [16] connectionInitiated(t = 0xfe503b5c), line 150 in "transport.c"
  [17] attachThread(ptr = 0xfe503b5c), line 177 in "transport.c"
  [18] DebuggerThread::start_function_wrapper(thread = 0x96fa8, __the_thread__ = 0x96fa8), line 2338 in "jvmdi.cpp"
  [19] JavaThread::thread_main_inner(this = 0x96fa8), line 1141 in "thread.cpp"
  [20] JavaThread::run(this = 0x96fa8), line 1125 in "thread.cpp"
  [21] _start(data = 0x96fa8), line 494 in "os_solaris.cpp"

Comments
EVALUATION This is part of a larger issue involving the handling of dead threads. They are very likely to show up and should be tested for. robert.field@Eng 2001-06-11
11-06-2001