Bug ID: JDK-4964067 SEGV in AsyncGetCallTrace during profiling

Type: Bug
Component: vm-legacy
Sub-Component: jvmpi
Affected Version: 5.0

Priority: P2
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2003-12-05
Updated: 2004-03-08
Resolved: 2004-03-08

Other
5.0 b42Fixed

AsyncGetCallTrace may crash JVM.


###@###.### 2003-12-22

This bug's description is pretty generic so I'm planning to use this
bug to track the fixes made during Tiger stress testing of the Forte
AsyncGetCallTrace() API.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b42 tiger-beta2
14-06-2004
EVALUATION ###@###.### 2003-12-22 I attacked the most frequent assert failure from the 2003.12.12 stress run first: assert(is_native() && bcp == code_base() \|\| contains(bcp), "bcp doesn't belong to this method") It appears that the following assertion failure is just a variation of the above: assert((is_native() && bci == 0) \|\| (!is_native() && 0 <= bci && bci < code_size()), "illegal bci") The initial proposed sender frame looks like an interpreted frame, but is really a mix of the real sender frame and the top frame which is under construction. Since it looks like an interpreter frame and it was not the top frame, we assumed it was valid. It looks like we need a new check to verify that the proposed initial sender frame has a valid method and BCI when it identifies itself as being interpreted. forte_is_walkable_frame() has a check for interpreted frames that does almost exactly what we need. I've refactored the code to create a new forte_is_walkable_interpreted_frame(). The refactored method is now used by forte_is_walkable_frame(). I've also added a check for the proposed initial sender frame to vframeStreamForte. ###@###.### 2003-12-23 The 'assert(pc_desc != 0,"scopeDesc must exist")' failure happens in at least two different code paths. I attacked the code path shown in threads.log.3015 because I already had debug code in place to show me what went wrong. The initial proposed sender frame is a compiled frame, but it does not have a PcDesc so it is not walkable. It looks like we need a new check in vframeStreamForte::vframeStreamForte() to verify that the proposed initial sender frame has a PcDesc when it identifies itself as being interpreted. forte_is_walkable_frame() has a check for walkable compiled frames that does almost exactly what we need. I've refactored the code to create a new forte_is_walkable_compiled_frame(). The refactored method is now used by forte_is_walkable_frame(). I've also added a check for the proposed initial sender frame to vframeStreamForte. ###@###.### 2004-01-08 The second 'assert(pc_desc != 0,"scopeDesc must exist")' code path needs a sanity check on the grandparent of the top_frame. The check can be done by another call to forte_is_walkable_compiled_frame(), but the call needs to be made in the vframeStreamCommon::next() routine. However, we don't want to modify the general purpose next() routine just for Forte. Looks like we need a Forte specific version of next() just like we have a Forte specific version of the constructor. ###@###.### 2004-01-28 The SIGBUS crash in frame::entry_frame_is_first() is yet another case of catching an interpreted frame too early in its life. Our initial sender frame contains an _interpreter_sp_adjustment field that results in adjusting the initial sender frame's SP to zero. This is because our peak into interpreted frame for the SP adjustment value yielded a zero. Why? In the case show in threads.log.3113 we caught the interpreted frame just as it was setting up the new stack frame. Ouch. Looks like we need a Forte specific version of safe_for_sender(). ###@###.### 2004-01-29 The second SIGBUS crash in frame::entry_frame_is_first() is yet another case of catching a frame too early in its life. Our top_frame identifies itself as an entry frame, but its JavaCallWrapper * is bogus. Looks like forte_safe_for_sender() need one more check. ###@###.### 2004-02-02 One of the two new infinite loop detection checks is needed on Solaris X86. Also forte_is_walkable_compiled_frame() needs to be called in the vframeStreamForte constructor on Solaris X86 in addition to Solaris SPARC. ###@###.### 2004-02-19 forte_is_walkable_interpreted_frame() needs to be called in the vframeStreamForte constructor on Solaris X86 in addition to Solaris SPARC. This should resolve assert(m->is_method(),"not a methodOop") failures with jvmg and SIGSEGV crashes in product bits with interpreted frames. ###@###.### 2004-02-20 Both Client and Server VMs on Solaris X86 have run into problems with a compiled frame that has no frame type. By "no frame type" I mean none of frame class type checkers, e.g., is_entry_frame(), return true. I never saw anything like this in my previous testing and development of AsyncGetCallTrace() so I'm isolating this sanity check in a new routine call is_unknown_compiled_frame().
11-06-2004
PUBLIC COMMENTS .
10-06-2004
SUGGESTED FIX ###@###.### 2004-03-11 See the attached forte-batch-20040227-webrev.tar.Z for the proposed changes. See the attached forte-batch-20040227-webrev-cr1.tar.Z for post code review version.
11-03-2004