Bug 52180 - Debugger stops at ghost breakpoint in mirror file.
Debugger stops at ghost breakpoint in mirror file.
Status: CLOSED FIXED
Product: debugger
Classification: Unclassified
Component: Code
4.x
All All
: P3 with 3 votes (vote)
: 6.x
Assigned To: Martin Entlicher
issues@debugger
: API, API_REVIEW_FAST
: 68095 70736 72409 74104 93339 103719 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-08 08:38 UTC by johnzoet
Modified: 2010-04-29 09:20 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The patch that fixes this issue, including a test. (27.66 KB, patch)
2006-05-03 17:31 UTC, Martin Entlicher
Details | Diff
Just the API change - subject of a review (3.12 KB, patch)
2006-05-03 17:31 UTC, Martin Entlicher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description johnzoet 2004-12-08 08:38:01 UTC
Given 2 projects with similar (mirrored) package 
structure. 
Project1, package a, File1 
Project2, package a, File1 
 
Set breakpoint on line x in {Project1, File1} 
Now start Project2 in debug mode. 
Debugger stops in {Project1, File1, line x} 
although {Project1, File1, line x} does not have 
a breakpoint at line x. 
 
The first time this happened it was rather 
bewildering to see the debugger stop somewhere 
in the middle of nowhere.
Comment 1 Milan Kubec 2004-12-08 08:42:14 UTC
Reassigning for eval.
Comment 2 johnzoet 2004-12-08 08:44:58 UTC
Correction:  
=>  
Set breakpoint on line x in {Project1, File1}   
Now start Project2 in debug mode.   
Debugger stops in {Project1, File1, line x}   
although {Project1, File1, line x} does not have   
a breakpoint at line x.   
=>  
  
Should read:  
=>  
Set breakpoint on line x in {Project1, File1}   
Now start Project2 in debug mode.   
Debugger stops in {Project2, File1, line x}   
although {Project2, File1, line x} does not have   
a breakpoint at line x.   
=>  
  
Comment 3 Jan Jancura 2005-04-13 09:28:36 UTC
No chance to fix it in 4.1.
Comment 4 Libor Kotouc 2005-04-27 09:49:44 UTC
What kind of projects is it about?
Comment 5 johnzoet 2005-04-27 10:09:03 UTC
This is a Swing application. 
You can probably replicate this problem with any type of project. 
Even 1 class file will do to handle this as a test case. 
Comment 6 Alexander Kouznetsov 2005-05-20 13:22:17 UTC
Reproduced in for two Web Applications with breakpoint on index.jsp page. It is critical for JSE.
Comment 7 Martin Entlicher 2005-05-20 13:47:38 UTC
I do not think this is so critical - who has identical classes in different
projects?
The fix will likely not be easy...
Comment 8 Martin Entlicher 2005-05-20 13:49:13 UTC
Oops, I should rather wrote: Different classes with identical name and package.
Comment 9 Libor Kotouc 2005-05-20 13:53:18 UTC
There is issue #54449 filed for the web projects and another issue against
debuggerjpda which the former depends on.
Comment 10 Alexander Kouznetsov 2005-05-20 15:15:15 UTC
OK, it seems that 54449 is more critical. BTW, the projects structure was intended to reduce confusion between same placed files in different projects. So it is strange that such a problem still exist.
Comment 11 Martin Entlicher 2005-05-20 19:26:06 UTC
The fix would perhaps not be that hard, if the LineBreakpoint API was usable. It
has methods getSourcePath() and getSourceName(), which always return null,
because setSourcePath() and setSourceName() is never called!
Ridiculously, there's a test for it, which calls the set methods :-)

I'll try to find a place where to call these setters and then (hopefully) the
fix will be easy...
Comment 12 Martin Entlicher 2005-05-20 19:29:50 UTC
Also, there's absolutely no synchronization of setters/getters. But there is
nothing in the javadoc about thread safety! This needs to be corrected...
Comment 13 Libor Kotouc 2005-05-21 10:05:27 UTC
I have few notes about sourceName and sourcePath fields in LineBreakpoint:

1. JspLineBreakpoint sets them both (see JspLineBreakpoint ctor)
2. sourcePath field was added by me (see API change issue #54529); it was needed
for issue #54408.
3. The functionality is guarded by two tests I wrote - they are placed in
debuggerjpda module (see JspLineBreakpointTest). btw, I filed issue against
testing framework because there are some synchronization problems and these two
tests randomly fail in tests coming with daily builds

What is important to look at is LineBreakpointImpl's mechanism of retrieving
locations for setting line breakpoint (LineBreakpointImpl.getLocations()).
com.sun.jdi.Location.sourcePath() returns RELATIVE path, thus
LineBreakpoint.sourcePath field is also relative and thus it cannot be used for
making difference between two projects.
Ok, we can perhaps change the semantics of sourcePath field, but there
immediatelly arise several new problems (like how to obtain relative path within
LineBreakpintImpl and others).

I think we should take a short meeting on this issue.
Comment 14 Martin Entlicher 2005-05-23 16:43:41 UTC
1. O.K. But in Java it's not set at all.
2. You have added it into the API only. Not into the implementation. Therefore
the API is useless, since it does not return anything.

There are many places where is just LineBreakpoint.create(..) without setting
also source path & source name. This is natural, because these fields were added
*after* that code was written.

3. I do not care about the tests for now - the funtionality just does not work
in the product.

The fact that source path is relative is O.K. for me. There is URL, that is
absolute.

> I think we should take a short meeting on this issue.
We can. We need just to figure out where to set the source path & source name.
Also, should the API allow to return null?
Comment 15 Martin Entlicher 2005-05-25 15:06:59 UTC
I've added synchronization to getters/setters:

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/LineBreakpoint.java,v 
<--  LineBreakpoint.java
new revision: 1.8; previous revision: 1.7

I'll add a comment to getSourcePath() and getSourceName() that it can return null.
We can not rely on the URL, since JSP changes the URL to class name.
We would probably need another property that would indicate the location (e.g.
source root) of that breakpoint.
Comment 16 Martin Entlicher 2005-05-25 15:24:14 UTC
The comment about null return values is there for getSourceName() and
getSourcePath():

/cvs/debuggerjpda/api/src/org/netbeans/api/debugger/jpda/LineBreakpoint.java,v 
<--  LineBreakpoint.java
new revision: 1.9; previous revision: 1.8
Comment 17 Martin Entlicher 2006-03-10 15:10:41 UTC
*** Issue 70736 has been marked as a duplicate of this issue. ***
Comment 18 Martin Entlicher 2006-03-29 19:34:12 UTC
*** Issue 74104 has been marked as a duplicate of this issue. ***
Comment 19 Jesse Glick 2006-04-27 14:45:20 UTC
Clearly was not fixed in 5.0. IMHO this is a P2; note the seven votes and two
recorded duplicates plus reports from the feedback alias.

mrkam's comment from a year back sounds correct. The project system has
unambiguous information about which version of a class is being debugged,
provided the class was included in the startup classpath of the application -
AFAIK that is why there is a <classpath> param for <nbjpdastart>. So the
debugger should be able to find the correct sources reliably.

On a related note, the Sources window seems like it is useless as of NB 4.0. The
IDE already has a way of finding sources for any binary class, and if you have
sources you should use them, so why not delete this window? (There was an issue
somewhere that you should by default be able to step through JRE classes if you
had sources for them, i.e. do not treat JRE classes differently from other
classes, but I can't remember where it was.)

Also some possibly related bugs: issue #60640 and issue #48750. Those pertain to
finding sources for classes generally, so if this bug is only about breakpoints
being set incorrectly (while e.g. source stepping is fine), then they might not
be relevant.
Comment 20 Martin Entlicher 2006-04-27 16:00:19 UTC
I've actually already started to work on fixing this. This issue is fixable, but
it requires some (compatible) API changes.

After fixing this, it will be really important to solve also issue #63879,
because otherwise breakpoints put into JDK sources will not work by default.

We think it's really important to be able to disable debugging of JDK sources.
It was done for a reason this way.
Comment 21 Martin Entlicher 2006-05-03 17:30:23 UTC
Breakpoints in JSP seems to work fine - there is a condition for the context in
the corresponding line breakpoint.

For ordinary line breakpoints this is fixed by the attached patch...
Comment 22 Martin Entlicher 2006-05-03 17:31:18 UTC
Created attachment 30222 [details]
The patch that fixes this issue, including a test.
Comment 23 Martin Entlicher 2006-05-03 17:31:59 UTC
Created attachment 30224 [details]
Just the API change - subject of a review
Comment 24 Martin Entlicher 2006-05-03 17:34:08 UTC
Please review the attached API change in debugger. It just adds one simple
method into the SPI to be able to distinguish where the breakpoints belong to.
Comment 25 Martin Entlicher 2006-05-11 19:03:31 UTC
It's one week at apireviews, so I hope the review is O.K.
Therefore I'm going to commit the change tomorrow, May 12 in the evening CET.
Thanks.
Comment 26 Martin Entlicher 2006-05-12 17:54:38 UTC
Fixed in trunk:

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointImpl.java,v
 <--  BreakpointImpl.java
new revision: 1.27; previous revision: 1.26

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointsReader.java,v
 <--  BreakpointsReader.java
new revision: 1.2; previous revision: 1.1

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/ClassBasedBreakpoint.java,v
 <--  ClassBasedBreakpoint.java
new revision: 1.12; previous revision: 1.11

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/LineBreakpointImpl.java,v
 <--  LineBreakpointImpl.java
new revision: 1.26; previous revision: 1.25

/cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/LineBreakpointTest.java,v
 <--  LineBreakpointTest.java
new revision: 1.11; previous revision: 1.10

/cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/SourcePath.java,v  <--
 SourcePath.java
new revision: 1.6; previous revision: 1.5

/cvs/debuggerjpda/api/src/org/netbeans/spi/debugger/jpda/SourcePathProvider.java,v
 <--  SourcePathProvider.java
new revision: 1.3; previous revision: 1.2

/cvs/debuggerjpda/ant/src/org/netbeans/modules/debugger/projects/SourcePathProviderImpl.java,v
 <--  SourcePathProviderImpl.java
new revision: 1.13; previous revision: 1.12

/cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/test/TestEngineContextProvider.java,v
 <--  TestEngineContextProvider.java
new revision: 1.9; previous revision: 1.8

/cvs/debuggerjpda/api/apichanges.xml,v  <--  apichanges.xml
new revision: 1.13; previous revision: 1.12

/cvs/debuggerjpda/api/manifest.mf,v  <--  manifest.mf
new revision: 1.17; previous revision: 1.16
Comment 27 Martin Entlicher 2006-06-28 16:09:32 UTC
*** Issue 72409 has been marked as a duplicate of this issue. ***
Comment 28 Martin Entlicher 2006-07-03 16:43:35 UTC
*** Issue 68095 has been marked as a duplicate of this issue. ***
Comment 29 Martin Entlicher 2007-02-23 17:49:27 UTC
*** Issue 93339 has been marked as a duplicate of this issue. ***
Comment 30 Martin Entlicher 2007-05-11 14:38:07 UTC
*** Issue 103719 has been marked as a duplicate of this issue. ***
Comment 31 Quality Engineering 2010-04-29 09:20:31 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo