This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 198764 - Hidden breakpoints from wrong projects
Summary: Hidden breakpoints from wrong projects
Status: RESOLVED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 7.1
Hardware: PC Mac OS X
: P2 normal with 3 votes (vote)
Assignee: Martin Entlicher
URL:
Keywords:
: 236328 242663 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-20 13:09 UTC by Tomas Stupka
Modified: 2015-09-24 01:28 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
example project (3.26 KB, application/x-java-archive)
2014-09-19 08:27 UTC, heapifyman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Stupka 2011-05-20 13:09:48 UTC
i have two project groups, where each one has opened different projects from different netbeans clones.

while i had activated the second group and was debugging a project from it, the debugger also stopped on breakpoints which were defined on the first project groups source tree. Unfortunately, i wasn't able to switch to the source from the debugging view as well as the relevant breakpoint wasn't listed in the breakpoint window.
Comment 1 Martin Entlicher 2011-11-16 11:20:45 UTC
Does this concern Java line breakpoints?
I can not reproduce this.
I've created two AnagramGame projects, put them in two different project groups and breakpoints work correctly...
Comment 2 Tomas Stupka 2011-11-16 12:45:57 UTC
can't reproduce with AG either.
it happened with a netbeans module from two different clones. i'll you know as soon it appears again
Comment 3 Martin Entlicher 2011-11-16 13:31:40 UTC
Unfortunately, I'm not able to reproduce it even on two NetBeans clones.
If this happens again, I'd appreciate steps to reproduce and zipped user dir.
Comment 4 maxnitribitt 2012-06-25 06:14:29 UTC
This might be the reason for the problems I currently have. The debugger stops at a line of code that is not shown in my breakpoints list, so i have no chance of  removing that breakpoint. So far I had no idea, where this might come from, but reading this, I had this project open in different versions of NetBeans (7.1.1, 7.1.2, 7.2 development build). Currently it's opened in Build 201205190400, and I can see the problem.
Comment 5 Martin Entlicher 2014-03-10 10:08:05 UTC
*** Bug 242663 has been marked as a duplicate of this bug. ***
Comment 6 Martin Entlicher 2014-03-10 10:10:43 UTC
*** Bug 236328 has been marked as a duplicate of this bug. ***
Comment 7 heapifyman 2014-09-16 09:52:33 UTC
I have a similar problem, the following messages keep showing up in Debugger Console:
Not able to submit breakpoint LineBreakpoint XYZ.java : 157, reason: The breakpoint is set outside of any class.
Invalid LineBreakpoint XYZ.java : 157

Point is that class XYZ.java is part of a project which is in a different project group. A project, which has never been open in this particular project group I am currently working in.

This does not seem to impact debugging per se but it is very annoying!
Comment 8 Jiri Kovalsky 2014-09-16 16:29:55 UTC
Can you please share with us your project sources? What kind of project is that? We cannot reproduce it and without any more information we cannot do something about it.
Comment 9 heapifyman 2014-09-19 08:25:57 UTC
> Can you please share with us your project sources? What kind of project is that? We cannot reproduce it and without any more information we cannot do something about it.

I attached a simple maven project, where the issue occurs.
Project has been created from Netbeans maven project wizard in an existing, empty project group (let's call it X). --> Debugging the project there gave the following output in Debugger Console:
Listening on 57356
Not able to submit breakpoint LineBreakpoint AGResource.java : 157, reason: The breakpoint is set outside of any class.
Invalid LineBreakpoint AGResource.java : 157
Not able to submit breakpoint LineBreakpoint App.java : 34, reason: The breakpoint is set outside of any class.
Invalid LineBreakpoint App.java : 34
Not able to submit breakpoint LineBreakpoint MockupScheduledPoll.java : 96, reason: The breakpoint is set outside of any class.
Invalid LineBreakpoint MockupScheduledPoll.java : 96
User program running
LineBreakpoint App.java : 15 successfully submitted.
Breakpoint hit at line 15 in class org.example.mavenproject1.App by thread main.
Thread main stopped at App.java:15.
User program running
User program finished

The first invalid breakpoint is from a project in ProjectGroup A
The second and third from a different projects in a different ProjectGroup B
Comment 10 heapifyman 2014-09-19 08:27:51 UTC
Created attachment 149356 [details]
example project
Comment 11 Jiri Kovalsky 2014-10-22 11:10:22 UTC
Product Version: NetBeans IDE 8.0 (Build 201403101706)
Updates: Updates available to version NetBeans 8.0.1 Patch 1.1
Java: 1.7.0_67; Java HotSpot(TM) 64-Bit Server VM 24.65-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_67-b01
System: Linux version 3.13.0-24-generic running on amd64; UTF-8; en_US (nb)

Just for the record, I still cannot reproduce it. I have two project groups A and B. A contains JavaSE mavenproject1 with line 15 breakpoint set in org.example.mavenproject1.App class. B contains different JavaSE mavenproject1 with line 27 breakpoint set in org.example.mavenproject1.App class. It also contains JavaEE mavenproject2 with line 17 breakpoint set in com.mycompany.mavenproject2.NewClass class. I can debug both project groups without facing any breakpoint mismatches.
Comment 12 kidnapper 2014-10-22 11:47:14 UTC
In my case the error happens under the following scenarios:
* project group A contains a large multimodule maven project (project A), and one of the module's has a dependency on a given version of project B. (project B is *not* part of project group A)
* project group B contains a bit smaller freeform ant project (but I think I've seen this with a small multi-module Maven project as well) called project B.

1) Set a breakpoint in project B in a given class.
1.5?) It may be necessary to actually debug project B on its own to trigger the bug(?)
2) switch to project group A
3) start to debug project A (since this is a Java EE project I'm using Attach Debugger against port 9009 - the project runs in GlassFish)
4) even though project B is not loaded, the debugger stops on breakpoints (visible in the debugger output panel), and the breakpoints are not visible in the breakpoint panel.
Comment 13 kidnapper 2014-10-22 11:49:23 UTC
Is it possible that bug 227076 is related to this one?
Comment 14 Martin Entlicher 2015-09-23 07:20:15 UTC
I have found following specific steps to reproduce:

- Have 2 NB repositories in 2 project groups.

- In repo1 open debugger.jpda project.
  Then open debugger.jpda.ui project,
   add line breakpoint somewhere into the constructor of ConnectPanel
   and close the debugger.jpda.ui project.
- Debug on debugger.jpda project, in the newly started IDE invoke:
   Debug/Attach Debugger.
  Line breakpoint in ConnectPanel from repo1 is hit as expected.
- Finish debugging
- Open the second project group on repo2. Open debugger.jpda project in it.
- Debug on debugger.jpda project, in the newly started IDE invoke:
   Debug/Attach Debugger.
  Line breakpoint in ConnectPanel from repo2 is hit!
   No breakpoint annotation is visible, since the breakpoint is
   in ConnectPanel from repo1.
Comment 15 Martin Entlicher 2015-09-23 07:30:46 UTC
Fixed by changeset:   292448:cc2b5a5ebc57
http://hg.netbeans.org/core-main/rev/cc2b5a5ebc57
Comment 16 Quality Engineering 2015-09-24 01:28:44 UTC
Integrated into 'main-silver', will be available in build *201509240002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/cc2b5a5ebc57
User: mentlicher@netbeans.org
Log: #198764: Check whether breakpoints from other sources have the same URL as is the URL to which the breakpoint's class resolves.