JDK-4762958 : occasional crashes/deadlocks from AsyncGetCallTrace()
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.2,1.4.2_02
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_9
  • CPU: generic
  • Submitted: 2002-10-15
  • 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 Availability Release.

To download the current JDK release, click here.
Other
1.4.2_02 02Fixed
Related Reports
Duplicate :  
JDK-4876597 - AsyncGetCallTrace crash in forte_is_walkable_frame()
Relates :  
JDK-4808151 - crash in AsyncGetCallTrace() when invoked during Deoptimization
Description
This bug is recorded to collect all available information on AsyncGetCallTrace()
failures. See Comments for more details.

###@###.### 2003-03-14

I believe all of the original crashes and deadlocks are now covered by
other bugs. I'm hijacking this bug to cover a specific deadlock case
between the safepoint mechanism and AsyncGetCallTrace().
Comments
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 tiger-b10
14-06-2004
EVALUATION ###@###.### 2002-10-24 The first crash has been fixed by 4759962. The second and third stack traces look like there are other corner cases that the stack is not in a good state to do stack walking. ###@###.### 2003-01-24 The second case in this bug (crash while thread is doing deoptimization) has been ocurring quite a bit in our testing, and we've just opened a new bug, 4808151, to cover that case specifically. ###@###.### 2003-03-13 Just to review the bidding: - first stack trace (12 Sep 2002): a deadlock fixed by 4759962. - second stack trace (27 Sep 2002): SIGSEGV crash tracked by 4808151 - third stack trace (15 Oct 2002, Volano): SIGSEGV in vframeStream() I believe my fix for the following bug will address the third stack trace: 4820592 4/4 AsyncGetCallTrace: assert(pc_desc != 0, "scopeDesc must exist") - fourth stack trace (Feb 6 2003): SIGBUS in is_walkable_frame() - fifth stack trace (Feb 27 2003): SIGBUS in is_walkable_frame() I believe my fix for the following bug will address the fourth and fifth stack traces: 4757672 3/3 AsyncGetCallTrace() on Solaris/Intel core dumps with assertion failure One of my tasks was to apply changes that Karen made during the Solaris X86 port to the Solaris SPARC port. This included making is_walkable_frame() code match more robust code from frame::profile_find_Java_sender_frame. I believe that all the issues identified in this bug are addressed, but I'm leaving it open until the Forte folks have a chance to take the new code out for a spin. ###@###.### 2003-03-14 I'm hijacking this bug to cover a deadlock between the safepoint mechanism and AsyncGetCallTrace(). ###@###.### 2003-03-17 I'm also adding a rare race condition that can occur during initial class loading. A for-loop assumes the initial frame always has a sender which isn't true with AsyncGetCallTrace(). ###@###.### 2003-03-27 I'm adding two assertion failures that I saw with Server VM testing. We incorrectly assume that the initial frame derived from the JavaThread's JavaFrameAnchor is safe for sender walking. We also incorrectly assume than an i2c adapter frame is always well formed. These last two assumptions are fine for the regular system, but not with AsyncGetCallTrace(). ###@###.### 2003-04-08 I'm adding two more failures that I observed with Java2Demo testing with the Server VM on X86. We incorrectly assume that the sender of a frame verified as walkable via forte_is_walkable_frame() is also walkable. We also incorrectly assume that a compiled frame is well formed. These last two assumptions are just fine for the regular system. Just not with AsyncGetCallTrace().
11-06-2004
PUBLIC COMMENTS .
10-06-2004