JDK-5050705 : Async exception installed during exception processing causes segv.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-05-20
  • Updated: 2004-08-17
  • Resolved: 2004-06-15
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_06 06Fixed
Related Reports
Relates :  
JDK-5051064 - Error: assert(pc_desc != 0,"Must be able to find matching PcDesc")
Description
I was investigating bug 5040492 and developed a test case for what I think
was causing it and an it with 1.5.b51 and it seg. faults. With java_g
it asserts. My test case still has bugs in it so it will hang once in a
while but I've attached it in its current form anyway.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic tiger-rc FIXED IN: 1.4.2_06 tiger-rc INTEGRATED IN: 1.4.2_06 tiger-b56 tiger-rc
18-08-2004
EVALUATION This is a bug in the fix for 4998314. By repeatedly calling handle_exception_C_helper if an async exception gets installed we effectively unwind the stack at each pass. We can then see "exception pc's" that are not compiled code (say we started out in an i2c adapter). This either blows an assert: assert (cb->is_nmethod(), ""); or causes us to segfault when we call nmethod functions on a non nmethod. Looks to me that the proper fix to 4998314 is to defer async exceptions until we are not in the middle of processing an exception. ###@###.### 2004-05-20
20-05-2004