Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 48130

Summary: Breakpoint in renamed project leads to exception
Product: [Eclipse Project] JDT Reporter: Henrich Kraemer <henrich.kraemer>
Component: DebugAssignee: Darin Swanson <Darin_Swanson>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: darin.eclipse
Version: 3.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Logfile containing exceptions none

Description Henrich Kraemer CLA 2003-12-04 20:32:55 EST 
I ran into this originally in a more elaborate plugin development scenario on 
2.1.1.
However I can reproduce it with 3.0 M5 as well. Here are the steps:
1. Create a simple java project with one class and a main method.
2. Set a breakpoint in the main method.
3. Create a launch configuration of type application 
4. debug and observe how the breakpoint is hit correctly
5. refactor the project's name.
6. Go into the debug debug perspective.
There will be exceptions in the .log file or ErrorLog window.
Comment 1 Henrich Kraemer CLA 2003-12-04 20:34:52 EST 
Created attachment 7069 [details]
Logfile containing exceptions

This is from the original situation, repeated twice.
Comment 2 Darin Wright CLA 2003-12-10 15:19:34 EST 
Could not reproduce problem. It looks like the breakpoints view was attempting 
to render a breakpoint that no longer exists. When I try this, the breakpoint 
is removed as expected (when a project is renamed). We intend to improve this 
with refactoring support in 3.0, such that the breakpoint remains.

However, I did remove unecessary logging of exceptions from BreakpointUtils and 
JDIModelPresentation.
Comment 3 Darin Wright CLA 2003-12-10 15:19:49 EST 
Please verify, Darin (S).
Comment 4 Darin Swanson CLA 2003-12-10 16:58:57 EST 
I can reproduce the problem on 20031209..the breakpoint is not removed.
With the changes nothing is logged to the Error Log but I am now left with a 
breakpoint that has as a label "<not responding>". Investigating.
Comment 5 Darin Wright CLA 2003-12-10 17:01:59 EST 
Good - that you can reproduce it (and that label is expected in the case of a 
missing type). However, the breakpoint should get deleted.
Comment 6 Darin Swanson CLA 2003-12-11 18:24:59 EST 
There resource change listener which leads to the element changed notification 
is for post change. We are only post auto build. So we get told about the Java 
types that have been deleted before the auto build has completed and before we 
have loading the breakpoints for the project that has just opened (and has the 
marker with the old type handle).
Comment 7 Darin Wright CLA 2003-12-17 17:26:52 EST 
The problem is with the project rename. The change notification has changed 
somehow. When you rename a single compilation unit, breakpoints are cleaned up 
fine (i.e. auto-deleted). The same used to happen with project renames. I 
could not find a simple fix for M6.

The side effect is that you have to manually delete the breakpoints yourself 
(from the breakpoints view). Marking as a dup since this will just be replaced 
by refactoring support, rather than a fix (see bug 7552).

*** This bug has been marked as a duplicate of 7552 ***