JDK-6936709 : AsyncGetCallTrace doesn't handle inexact stack walking properly
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2010-03-19
  • Updated: 2010-09-24
  • Resolved: 2010-04-21
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 Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs18Fixed
Related Reports
Relates :  
Description
AsyncGetCallTrace often returns traces that report a 0 bci.  The problem is that the logic in is_decipherable_compiled_frame has two tests that look like this:

  if (pc_desc != NULL &&
      pc_desc->scope_decode_offset() == DebugInformationRecorder::serialized_null) {

that should be:

  if (pc_desc == NULL ||
      pc_desc->scope_decode_offset() == DebugInformationRecorder::serialized_null) {

The existing logic keeps us from doing searching nearby for valid PcDescs and selecting them as the start of the stack walk.  I would have expected vframeStream to assert about this but it apparently does not.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/547cbe6dacc5
08-04-2010

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/547cbe6dacc5
02-04-2010

EVALUATION The tests should be recoded as suggested and we may want to revisit the logic for picking a nearest pcdesc since it will search forward instead of backward.
19-03-2010