-
Bug
-
Resolution: Fixed
-
P3
-
hs17
-
b03
-
sparc
-
solaris_9
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2191962 | 7 | Tom Rodriguez | P3 | Closed | Fixed | b90 |
JDK-2197994 | 6u23 | Tom Rodriguez | P3 | Resolved | Fixed | b01 |
JDK-2199944 | 6u22m | Tom Rodriguez | P3 | Resolved | Fixed | b01 |
JDK-2193601 | 6u21p | Tom Rodriguez | P3 | Resolved | Fixed | b03 |
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.
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.
- backported by
-
JDK-2193601 AsyncGetCallTrace doesn't handle inexact stack walking properly
- Resolved
-
JDK-2197994 AsyncGetCallTrace doesn't handle inexact stack walking properly
- Resolved
-
JDK-2199944 AsyncGetCallTrace doesn't handle inexact stack walking properly
- Resolved
-
JDK-2191962 AsyncGetCallTrace doesn't handle inexact stack walking properly
- Closed
- relates to
-
JDK-6603919 Stackwalking crash on x86 -server with Sun Studio's collect -j on
- Closed