Bugzilla – Full Text Bug Listing
| Summary: | Breakpoint undo should not automatically register a breakpoint | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Rennie <Michael_Rennie> | ||||||
| Component: | Debug | Assignee: | Dani Megert <daniel_megert> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | curtis.windatt.public, daniel_megert | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | 3.7 M5 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
digging a bit deeper I remembered that when we delete a breakpoint we set its' registered state to false, so even during the restore code the marker will not have the right state to restore the registered state. We need to store the registered state somehow and properly restore it when the breakpoint deletion is undone. (In reply to comment #1) > digging a bit deeper I remembered that when we delete a breakpoint we set its' > registered state to false, so even during the restore code the marker will not > have the right state to restore the registered state. > > We need to store the registered state somehow and properly restore it when the > breakpoint deletion is undone. Either that (preferred) or add something to the marker before we delete it. Fixed in HEAD. Available in builds >= N2011013-2000. Verified that the tests are green again except for the following test which only failed on Mac (and which I can't check since I have no Mac): testRunToLine Error N/A java.lang.NullPointerException at org.eclipse.jdt.debug.tests.breakpoints.RunToLineTests.runToLine(RunToLineTests.java:188) at org.eclipse.jdt.debug.tests.breakpoints.RunToLineTests.testRunToLine(RunToLineTests.java:86) at org.eclipse.jdt.debug.tests.AbstractDebugTest.runBare(AbstractDebugTest.java:1763) at org.eclipse.jdt.debug.tests.DebugSuite$1.run(DebugSuite.java:54) at java.lang.Thread.run(Thread.java:613) and which might be unrelated. Mike can you verify with your manual test cases? Created attachment 186718 [details]
Fix
Created attachment 186719 [details]
Fix
+1 works fine |
code from HEAD (testing in I20110104-0920) While testing the undo support for breakpoints I discovered some breakpoints sporadically showing up in the view. I my case there were 4 that would show randomly: 1. a Java exception breakpoint for java.lang.Exception 2. a Java exception breakpoint for java.lang.Throwable 3. a JSDT script load breakpoint for global script load 4. a JSDT script exception breakpoint When I dug deeper I realized these are the breakpoints that back the JDT debug option for suspending on uncaught exceptions (1 and 2) and the breakpoints that back the JSDT debug options for suspending on exceptions and all script loads. It seems that this code in BreakpointManager line 790 causes the issue: else if (getBreakpoint(marker) == null) { try { IBreakpoint breakpoint= createBreakpoint(marker); breakpoint.setRegistered(true); fAdded.add(breakpoint); } ... where the problem comes from setting any one of these breakpoints as registered: doing so makes them visible in the breakpoints view. When we are re-creating the breakpoint for the marker we should only call the setRegistered(..) method if the registered attribute on the marker is set to true. Setting the registered stated of a breakpoint is a very common way to 'hide' a breakpoint from users, as it causes it to not show in the breakpoints view, we should make sure to preserve this state. The bug seems to be timing sensitive, but the steps I used to reproduce: 1. create simple class with main method 2. check on the JDT > Debug > suspend on all uncaught exceptions preference 3. restart workbench 4. debug the simple class After a few iterations of this you should see one (or all) of the breakpoints mentioned appear in the breakpoints view (you will need to have JSDT installed to see the last two). See the JavaDebugOptionsManager class for more details on where / how the hidden exception breakpoints are created.