Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 48130 - Breakpoint in renamed project leads to exception
Summary: Breakpoint in renamed project leads to exception
Status: RESOLVED DUPLICATE of bug 7552
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Darin Swanson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-04 20:32 EST by Henrich Kraemer CLA
Modified: 2003-12-17 17:26 EST (History)
1 user (show)

See Also:


Attachments
Logfile containing exceptions (29.47 KB, text/plain)
2003-12-04 20:34 EST, Henrich Kraemer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 ***