JDK-4820592 : AsyncGetCallTrace: assert(pc_desc != 0, "scopeDesc must exist")
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.1,1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-02-19
  • Updated: 2003-07-18
  • Resolved: 2003-06-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
1.4.2_02 02Fixed
Related Reports
Relates :  
###@###.### 2003-02-19

Stress testing of the AsyncGetCallTrace() interface has exposed an
intermittent assertion failure:

# assert(pc_desc != 0, "scopeDesc must exist")
# Error ID: src/share/vm/runtime/vframe.cpp, 524

During the stack walk, vframeStream finds a compiled frame for which it
cannot find a scope description. Here is a snippet of the stack trace:

  [6] report_assertion_failure(code_str = 0xfefdebdb "pc_desc != 0", file_name =
 0xfefdebe8 "/work/ws/hotspot/main/baseline-exp/src/share/vm/runtime/vframe.cpp"
, line_no = 524, message = 0xfefdec2b "scopeDesc must exist"), line 237 in "debu
  [7] vframeStream::fill_from_frame(this = 0xffbed538), line 524 in "vframe.cpp"
  [8] vframeStream::vframeStream(this = 0xffbed538, thread = 0x3e440, top_frame
= CLASS, stop_at_java_call_stub = 0), line 572 in "vframe.cpp"
  [9] forte_fill_call_trace_given_top(thd = 0x3e440, trace = 0xfc6a1850, depth =
 50, top_frame = CLASS), line 177 in "forte.cpp"
  [10] AsyncGetCallTrace(trace = 0xfc6a1850, depth = 50, ucontext = 0xffbed9b8),
 line 313 in "forte.cpp"
  [11] profhandler(0x1d, 0xffbedc70, 0xffbed9b8, 0x0, 0x0, 0x0), at 0xfc690c3c
  [12] __sighndlr(0x1d, 0xffbedc70, 0xffbed9b8, 0xfc690a80, 0x0, 0x0), at 0xff37
  [13] call_user_handler(0xff3875a8, 0x1, 0xff387b20, 0xffbed9b8, 0xffbedc70, 0x
1d), at 0xff36fadc
  [14] sigacthandler(0xff3875a8, 0xffbedc70, 0xffbed9b8, 0xff386000, 0xffbedc70,
 0x1d), at 0xff36fca8
  ---- called from signal handler with signal -13077080 (SIG-13077080) ------
  [15] 0xf9d02c04(0xf18283c0, 0xf18283a8, 0x8, 0x0, 0xffbee120, 0x3ea58), at 0xf
  [16] 0xf9c001c8(0xffbedde0, 0xffbee038, 0xa, 0xf5844d18, 0xf9c0c560, 0xffbee10
4), at 0xf9c001c7
  [17] JavaCalls::call_helper(result = 0xffbee030, m = 0xffbedf8c, args = 0xffbe
e0f8, __the_thread__ = 0x3e440), line 364 in "javaCalls.cpp"

The full stack trace for the java_g crash is attached as threads.log.4.

This failure reproduces in a different way with the java cmd:

# Error ID: 43113F32554E54494D45110E4350500308 01

The ErrorID maps to: c1_Runtime1.cpp, 776

The code is in src/share/vm/c1/c1_Runtime1.cpp:

  // exception must have happened inside an nmethod
  CodeBlob* cb = CodeCache::find_blob(pc);
  guarantee(cb != NULL && cb->is_nmethod(),
    "exception happened outside interpreter, nmethods and vtable stubs");

Here is a snippet of the stack trace:

  [6] report_fatal(0xfefa73bc, 0x308, 0xfefa73ff, 0x0, 0x0, 0x0), at 0xfee355f4
  [7] Runtime1::return_address_for_exception(0x0, 0xfa46f800, 0x0, 0x0, 0x0, 0x0
), at 0xfeded558
  [8] 0xfa46f804(0x0, 0xfa4871c4, 0x1, 0xfa4871c4, 0x31ef98, 0xfecd2da8), at 0xf
  [9] vframeStream::fill_from_frame(0xffbed858, 0x0, 0xffbed870, 0x0, 0x20, 0x0)
, at 0xfecd2e74
  [10] vframeStream::vframeStream(0xffbed858, 0x2ccd0, 0xffbed848, 0x0, 0xffbed9
b8, 0x0), at 0xfef851b4
  [11] forte_fill_call_trace_given_top(0x2ccd0, 0xfcfc1850, 0x32, 0xffbeda30, 0x
0, 0x0), at 0xfee3b244
  [12] AsyncGetCallTrace(0xfcfc1850, 0x32, 0xffbedcb0, 0x0, 0x0, 0xfcfc17c0), at
  [13] profhandler(0x1d, 0xffbedf68, 0xffbedcb0, 0x0, 0x0, 0x0), at 0xfcfb0c3c
  [14] __sighndlr(0x1d, 0xffbedf68, 0xffbedcb0, 0xfcfb0a80, 0x0, 0x0), at 0xff37
  [15] call_user_handler(0xff3875a8, 0x1, 0xff387b20, 0xffbedcb0, 0xffbedf68, 0x
1d), at 0xff36fadc
  [16] sigacthandler(0xff3875a8, 0xffbedf68, 0xffbedcb0, 0xff386000, 0xffbedf68,
 0x1d), at 0xff36fca8
  ---- called from signal handler with signal -13077080 (SIG-13077080) ------
  [17] 0xfa486fc4(0xf2075a78, 0xf2075a60, 0x0, 0xf6001e00, 0x337940, 0xfecba1e4)
, at 0xfa486fc3
  [18] 0xfa400118(0xffbee0d8, 0xffbee240, 0xa, 0xf6042c30, 0xfa40aae0, 0xffbee2f
4), at 0xfa400117
  [19] JavaCalls::call_helper(0xffbee238, 0xffbee190, 0xffbee2ec, 0x2ccd0, 0x2cc
d0, 0x0), at 0xfecc7534

The full stack trace for the java crash is attached as threads.log.2.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b08

EVALUATION ###@###.### 2003-02-19 Steve G. and I have exchanged a number of e-mail messages about this bug. What we discovered is that the SIGPROF signal has come in right in the middle of a Java call. There is a compiled frame on the stack that is starting to make a call to another Java method. When we ask for the current frame what we get back is a combination of information from two frames: - some information is from the compiled frame (the real sender) - some information is from the new frame (the callee) We try to use this mix of information to find the "sender" of the current frame. However, this doesn't work quite right because the current frame is not completely setup. We wander up the call stack until we fail an assertion with java_g or crash with java. The vframeStream code is working correctly for the regular system and we don't want to change that. The problem that we are seeing with AsyncGetCallTrace() is limited to that API only. In the regular system, the new frame (the callee) is stable by the time any stack walker tries to do its work. It is the asynchronous nature of AsyncGetCallTrace() that is allowing the API to see the incomplete stack frame.