Bugzilla – Full Text Bug Listing
| Summary: | debug breaks on caught exception on jdk 1.4.2 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | quartz quartz <quartz12h> | ||||||
| Component: | Debug | Assignee: | Luc Bourlier <eclipse> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | makoto_wada_jp | ||||||
| Version: | 3.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
That looks like a VM problem for me. By default, the debugger ask the VM to stop on uncaught exception (only). But it appears that sun VM 1.4.2 does not get the right caught/uncaught status in this case, and suspend because it thinks this exception is not caught. You can unset 'suspend on uncaught exception' in window>preferences>java>debug. We had a bug related to this in M4. What build are you using? i am using 3.0 i20030910. *** This bug has been marked as a duplicate of 44759 *** Created attachment 6885 [details]
jdb debug trace
I can reproduce the proble with I200311192030 on sun 1.4.2 and with jdb from
sun 1.4.2.
I was too slow ... I think it's a VM problem, I haven't find anything in Sun bug database. thanks for reporting it to sun. (I assume you had/will because you know much better than I what is involved during debugging). Luc, please open a Sun bug report, and then close this bug. I filled a Sun bug report (Review ID: 228951). Now waiting that they evaluate my report (that can take 3 weeks). The bug report has been accepted by Sun. http://developer.java.sun.com/developer/bugParade/bugs/4965317.html Closing this bug. after investigation, Sun says this is not a bug, http://developer.java.sun.com/developer/bugParade/bugs/4965317.html I tryed with latest jdk Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) and put back both the suspend on uncaught/caught exception and eclipse i20040121 still stop for this TimeZone.getTimeZone("UTC") example. Marking as wontfix. There is nothing we can do, it's a limitation of the VM. In this specific case, it does not get the right caught/uncaught status. We have to believe what the VM says, because we have no better way to get this information. I knew this was a common VM problem, but not that the spec says the information can be wrong. There are more information about this problem in the javadoc of ExceptionEvent#catchLocation(). http://java.sun.com/j2se/1.4.2/docs/guide/jpda/jdi/com/sun/jdi/event/ExceptionEvent.html#catchLocation() well, somebody has to fix something... can you rephrase the bug to sun so that they understand that the information is wrong, as you say? Because you definitely found a bug. You just need to communicate it in a way that sun will understand and acknoledge it. maybe if you take the "clarify spec" approach, they will jump on it, then at the next iteration, they will be forced to fix the bug...! Thanks. or better, request-for-enhancements. Seams to me that the jdi, aware of any native stackframe, could fire the exception event with an additionnal flag telling if the exception is under a native call. That way, in eclipse, you could offer an option like "ignore uncaught exception behind native calls". simple enough. good luck. I stay tuned. Sorry, you were wrong saying that you couldn't do anything. You can do something: walk up StackFrames in the BreakPointEvent.thread().frames() list: if StackFrame.location().method().isNative() then ignore event. I knew nothing about jdi and it took me ~30 minutes to find that. (Pretty cool stuff that jdi... E.Gamma: is there a junit fixture that does code-coverage tests?) Created attachment 7925 [details]
simple jdi code to show and solve the problem
this show how we can simply detect the uncaught exceptions that are behind
native methods and decide if we want to resume or not (the 2 commented lines in
the jdi handler: if(behindNative) tr.resume())
reminder: we still can't debug a 1.4.2 jvm without disabling the "suspend on uncaught", which is overkill and does not help developpers to track the cause of an uncaught exception because it doesn't suspend the thread. I filed a feature request for the more general problem (bug 52063). Closing this bug. quarts12h: FYI, this is the only instance of this problem that had been reported to us. *** Bug 53346 has been marked as a duplicate of this bug. *** |
The sample code works fine in run mode. When in debug mode, it runs without breaking, on jdk 1.4.1 but on jdk 1.4.2 it breakpoints the thread on some file not found exception. As you resume, of course all is fine (time zone is not null, exception is caught internally). Basically, the problem is that eclipse breaks on the exception (which is not breakpointed), The FNFE is caught internally in the jre. Eclipse has always done that since any version of 1.4.2 are out. I just installed a fresh 1.4.2_02b3, and it still does that. 1.4.1 never did that. import java.util.TimeZone; public class jdk142exc { public static void main(String[] args) { TimeZone tz = TimeZone.getTimeZone("UTC"); System.out.println(tz); } }