Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 165742 - [67cat] Wrong debug sources
[67cat] Wrong debug sources
Status: RESOLVED FIXED
Product: debugger
Classification: Unclassified
Component: Java
6.x
PC Windows XP
: P2 with 1 vote (vote)
: 6.x
Assigned To: issues@debugger
issues@debugger
: REGRESSION
: 168511 (view as bug list)
Depends on: 167153
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-21 19:13 UTC by ulfzibis
Modified: 2011-07-29 14:10 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Wrong debug sources (153.56 KB, image/png)
2009-05-21 19:14 UTC, ulfzibis
Details
Sorry, does NOT WORKFORME. So I still have to add the right sources manually and deal with Issue 166801. (110.56 KB, image/png)
2009-07-15 15:17 UTC, ulfzibis
Details
Simply reproduced in recent dev build (imported favourite+toolbar+platform settings from 6.7.1) (151.53 KB, image/png)
2009-09-11 13:35 UTC, ulfzibis
Details
Wrong order of debug sources even on normal debug, JDK/scr.zip should be last (76.74 KB, image/png)
2009-09-11 15:04 UTC, ulfzibis
Details
Suitable order before starting debugger (134.69 KB, image/png)
2009-10-05 15:07 UTC, ulfzibis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ulfzibis 2009-05-21 19:13:22 UTC
[ BUILD # : 200905160201 ]
[ JDK VERSION : 1.6.* ]

Please refer to attachment.

I have started debugger from class "MyMap" in project, which is not
set as "Main Project".
As you see in debugger "Sources" window, wrong JDK platform sources
are listed.
Expected sources from Platform "JDK 1.6.0_03 debug", but have from
Platform "JDK 1.6 (default)".
... but other source paths from not_main_project are listed
correctly.
Comment 1 ulfzibis 2009-05-21 19:14:13 UTC
Created attachment 82580 [details]
Wrong debug sources
Comment 2 Martin Entlicher 2009-05-22 11:19:54 UTC
I've reproduced it. It happens only for projects with Compile on Save turned on. Therefore it's a regression caused by
introduction of Compile on Save feature.
Comment 3 Martin Entlicher 2009-05-22 11:49:47 UTC
<nbjpdastart> in build-impl.xml contains bootclasspath nested element:
                    <bootclasspath>
                        <path path="${platform.bootcp}"/>
                    </bootclasspath>
However, there's nothing like that in debug-snippet.xml! There's just classpath. Therefore debugger does not know the
platform bootclasspath and uses the default platform.
Comment 4 Martin Entlicher 2009-06-10 16:56:48 UTC
Marking as P2 because it's a regression.
Comment 5 Rastislav Komara 2009-07-14 17:42:42 UTC
fixed.
Comment 6 ulfzibis 2009-07-14 18:49:31 UTC
Can we have this for Hotfix 1 aka 6.7.1 ?
Comment 7 Quality Engineering 2009-07-15 07:21:21 UTC
Integrated into 'main-golden', will be available in build *200907150249* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2e37fbc109a4
User: Rastislav Komara <moonko@netbeans.org>
Log: #165742: Wrong debug sources
Comment 8 Marian Mirilovic 2009-07-15 07:55:10 UTC
Ulf, 
it's too late for 6.7.1 / Patch 1 ... but marked with appropriate SW so if we'll do patch 2 it will be there. Could you
please verify that it works in the latest trunk build ? Thanks in advance.
Comment 9 ulfzibis 2009-07-15 07:57:42 UTC
Rastislav,
I had a look in your changeset.
If I guess right, you are familiar in adding properties and embed their usage in standard build-impl.xml.

Maybe you would like to fix Issue 122677.

... it would make live so much easier running tests on forked JVMs.
Comment 10 ulfzibis 2009-07-15 08:20:15 UTC
> it's too late for 6.7.1 / Patch 1 ... but marked with appropriate SW so if we'll do patch 2 it will be there.

It seems, that I never could use official release build. I could start crying, it's enough to make me weep :-(

> Could you please verify that it works in the latest trunk build ? Thanks in advance.

I try since 1 hour. Upload seems in progress.
Comment 11 ulfzibis 2009-07-15 08:21:24 UTC
> it's too late for 6.7.1 / Patch 1 ... but marked with appropriate SW so if we'll do patch 2 it will be there.

It seems, that I never could use official release build. I could start crying, it's enough to make me weep :-(

> Could you please verify that it works in the latest trunk build ? Thanks in advance.

I try since 1 hour. Upload seems in progress.
Comment 12 ulfzibis 2009-07-15 09:27:27 UTC
> Could you please verify that it works in the latest trunk build ? Thanks in advance.

I have problems to reset all the settings, I've made for workaround.
Please vote for Issue 168597.
Comment 13 ulfzibis 2009-07-15 15:17:51 UTC
Created attachment 84787 [details]
Sorry, does NOT WORKFORME. So I still have to add the right sources manually and deal with Issue 166801.
Comment 14 ulfzibis 2009-07-15 15:20:33 UTC
Correction: Seems that debugger steps into right source, but "sources" window display is wrong.
Comment 15 Daniel Prusa 2009-07-15 16:15:13 UTC
*** Issue 168511 has been marked as a duplicate of this issue. ***
Comment 16 Rastislav Komara 2009-07-17 07:56:31 UTC
I consider this as fixed. It works for me. Please provide more information about environment and project (including
project as attachment if possible) prior to reopening.
Comment 17 ulfzibis 2009-07-17 08:33:34 UTC
How can you consider it as fixed, as you can clearly see on the screenshot, that there is wrong source (jdk src.zip
version 14 instead of 03) in wrong order (according to -Xbootclasspath/p: project sources should be scanned first)
displayed in debugger Sources window?

You can check out my project from https://java-nio-charset-enhanced.dev.java.net/. (choose rev 741 from trunk)
Please note the "run from NetBeans 6.7" instructions at the bottom of the page.
Comment 18 Jiri Prox 2009-07-21 11:16:01 UTC
I finally managed to reproduce it - the compile on save must be enabled, otherwise it work fine
Comment 19 David Strupl 2009-07-23 09:02:01 UTC
Marking this as P3 -- if there are steps to reproduce the problem starting with fresh project we can make it P2 but if
this is reproducible only using Ulf's project it will stay at P3.
Comment 20 ulfzibis 2009-07-24 08:10:30 UTC
A 2nd condition to reproduce this issue could be, that project runs on supplemental/external Java platform, so this
could be more than Ulf's project.

Comment 21 ulfzibis 2009-08-03 21:30:58 UTC
Maybe the order of configuring is important:
- run 6.7.1 first time and iport settings from 6.5 (including additional java platform, here: <jdk6u03 + jrl-sources>)
- open Debug Sources -> instead src.zip + jrl-sources from jdk6u03, have default_jdk src.zip (here: jdk6u14)
Later (IDE was closed) I renamed jrl-sources folder from 'src' to 'build-src'
- again run 6.7.1
- open java plaform manager, delete old paths and add new paths as they are renamed
- again open Debug Sources -> correctly src.zip + jrl-sources from jdk6u03 are included
Comment 22 Jan Lahoda 2009-08-20 10:01:05 UTC
Reassigning all moonko's java/source bugs to myself.
Comment 23 ulfzibis 2009-08-31 13:56:23 UTC
Reproduced in fresh standard Java project. See: Issue 171169.
Comment 24 Jan Lahoda 2009-09-11 10:27:52 UTC
I tried to reproduce with your project, but I failed. Please provide precise steps to reproduce on a recent trunk build,
from a clean userdir, ideally without upgrades, using an ordinary project with as little magic as possible (should not
be a problem, as you were able to reproduce with a new project in issue #171169, which then led to upgrade to P2 - what
puzzles me a bit is that issue #171169 contains screenshots from 6.7.1, which does not, to my knowledge, contain the
original fix, but as this bug was upgraded to P2 anyway, I assume you were able to reproduce on a trunk build). Your
reproducible case is very much appreciated. Thanks.
Comment 25 ulfzibis 2009-09-11 13:35:16 UTC
Created attachment 87502 [details]
Simply reproduced in recent dev build (imported favourite+toolbar+platform settings from 6.7.1)
Comment 26 ulfzibis 2009-09-11 13:54:39 UTC
With clean userDir:

- Add platform "JDK 1.7 ea fastdebug" (I'm using b70 currently)
- Open "Bugs" project
- Open ScannerTest and set BP on line 94
- Strg-Shift-F5
- Open Debugger Sources window
---> same bad result, e.g. jdk1.6.0_14\src.zip is in first position, instead of jdk1.7.0\fastdebug\src.zip
Comment 27 Jan Lahoda 2009-09-11 14:21:04 UTC
Aha, it is about debugging *test*. Should be fixed now:
http://hg.netbeans.org/jet-main/rev/e6d94018a804
Comment 28 ulfzibis 2009-09-11 14:36:29 UTC
Fine, I assumed debug *test* is obvious, as it is invoked automatically on editor-text-area-->right-click-->Debug

Have also considered the _right order_?
In case of "Ulf'f Project" it's important, that the JDK/src.zip should be *after* the last project's source roots.
Comment 29 ulfzibis 2009-09-11 15:04:09 UTC
Created attachment 87508 [details]
Wrong order of debug sources even on normal debug, JDK/scr.zip should be last
Comment 30 ulfzibis 2009-09-11 15:06:46 UTC
It remains wrong order of debug sources even on normal debug, which results in same problem, a little different way.

Comment 31 Quality Engineering 2009-09-13 21:06:11 UTC
Integrated into 'main-golden', will be available in build *200909131354* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e6d94018a804
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #165742: passing correct bootclasspath when debugging tests and applets.
Comment 32 David Strupl 2009-09-14 10:17:13 UTC
After Jan's fix this is no longer P2. Making it P3.
Comment 33 ulfzibis 2009-09-27 17:45:45 UTC
After this fix, situation is worse than before, because there is no workaround any more.

If there badly was jdk1.6.0_14\src.zip in debug sources, I could disable it, and manually add
jdk1.7.0\fastdebug\src.zip, but now, if jdk1.7.0\fastdebug\src.zip is correctly in debug sources, but in wrong position,
it doesn't help, to disable it, and again add it manually in right position.

So I still think, this issue is P2, as I can't do my work with 6.8dev.

Please note:
Before you run the debug session, order in debugger->sources window looks good, but after start of debug,
jdk1.7.0\fastdebug\src.zip jumps to 1st position, which is bad.

Comment 34 David Strupl 2009-09-27 19:42:16 UTC
The use case (to modify JDK classes and put them on bootclasspath) is not really common. Making this P3 again.
Comment 35 ulfzibis 2009-09-28 11:21:40 UTC
Hm, I guess that means, 6.8 likely will not fix this issue, so I have to stay on 6.7.1 with a workaround for long time.

I'm wondering:
1. The problem, to debug on the right sources, is worse than before, as this issue still was marked as P2 (regression).
2. _This use case_ is officially recommended for contributions on OpenJDK 6 + 7, which I do since more than a year, to
avoid building the whole JDK for each small source change.
  Are there so few OpenJDK contributors?
  I'm disappointed, that there is so bad support for using NetBeans to work on Sun's JDK.

  
Comment 36 Jan Lahoda 2009-09-29 14:43:34 UTC
A few comments/questions:
-the current scope of this bug is completely different from the original scope
-the cause of the current scope is clear: J2SE Project are not designed to allow changes in bootclasspath. So the
runtime bootclasspath is set using run.jvmargs=-Xbootclasspath/p:<something>. The project simply has no idea that the
user specified such a parameter. Not a defect, IMO. Contributions welcome.
-could you please point me to documentation that officially recommends this pattern to develop patches for OpenJDK? To
my knowledge, all OpenJDK projects are freeform projects (which, BTW, support bootclasspath changes).

Comment 37 Martin Entlicher 2009-09-29 15:28:15 UTC
Something that has worked before and now is marked as a REGRESSION should not be changed to enhancement IMHO.
I'm going to look at what debugger can see after http://hg.netbeans.org/main-golden/rev/2e37fbc109a4
Comment 38 Martin Entlicher 2009-09-29 17:13:42 UTC
Ulf, please let me know how do you have set the JDK sources.
I've tried to reproduce by adding an additional source folder in Tools -> Java Platforms to "Sources" tab of my JDK.
Moving the new source folder to the top also moves it to the top in debugger's Sources window.

Can you please test the behavior in the latest build at http://bits.netbeans.org/dev/nightly/latest/ and if it still
does not work, provide the details of the project setup? Thanks.
Comment 39 Martin Entlicher 2009-09-29 17:15:39 UTC
Also, please, try both variants with "Compile on Save" on and off. Thanks.
Comment 40 Jan Lahoda 2009-09-29 18:45:01 UTC
Fair enough. There are two interrelated things embedded in the last usecase:
-J2SE Project not supporting run.jvmargs=-Xbootclasspath/p:<something>. I still consider this to be an enhancement -
this never worked and was never supposed to work. Contributions are still welcome.
-the regression part (AFAIK): in 6.7, the bootclasspath was incorrect for CoS debugging, and Ulf was able to disable the
sources for the incorrect platform, and add sources for the correct one. As the newly added sources were behind the
project sources, the project sources were preferred. When we fixed CoS to include correct bootclasspath, Ulf is no
longer able to disable the sources for the platform and add them again, as this means adding the very same URL again.
There are obvious workarounds for this, e.g. make a copy of src.zip and add that copy instead of the original. But, the
inherent problem here is that Debugger/Sources does not allow to change order of source roots. I do not think there is
anything that could be done on java.source side to fix this (aside from reverting the fixes, which seems like a very
poor solution to me).

As the regression part needs to be solved on the debugger side, I am passing this issue there, and setting last values
Ulf set (P2/Defect).
Comment 41 Martin Entlicher 2009-09-29 19:03:28 UTC
O.K. Thanks.
Please track supporting run.jvmargs=-Xbootclasspath/p:<something> as a separate enhancement as debugger is not
interested in that at all provided we get that on bootclasspath.

IMHO it's important that the debugger gets the ORDER of source roots correctly (matching execution order) and I believe
that under such condition nobody wants to change the order of source roots.
From my point of view this is now fixed, Ulf please let me know the setup of your projects and what exactly is wrong there.

We have issue #166801 for the order of source roots. Thus if bootclasspath gives us the correct items with correct
order, this should be closed as fixed IMHO.
Comment 42 Jan Lahoda 2009-09-29 19:47:07 UTC
I filled #173310. I do not think that it can be guaranteed to have the sources and their order always correct - if the
project does classloader magic (which, btw, might be reasonable for java-nio-charset-enhanced as that would allow
running tests for the original charsets and new charsets in one instance of JVM and compare their performance), then the
order of jars on boot/execute classpath is not very relevant. I agree, though, that the IDE should do its best to
provide correct values, and it does so in supported usecases, I believe.
Comment 43 ulfzibis 2009-09-30 16:11:44 UTC
Set breakpoint to java.nio.charset.Charset1.lookup() and then advance by Step Over.
Comment 44 ulfzibis 2009-09-30 16:14:55 UTC
Last comment belongs to Issue 173405, sorry.
Comment 45 ulfzibis 2009-10-05 14:39:38 UTC
Last 2 weeks I had the flu, and was seriously ill, so please excuse my delayed and half-baked answers.

> -the current scope of this bug is completely different from the original scope
I think, there is no big difference. In the beginning, additionally to the bad order, we had wrong JDK's src.zip in
debugger sources.

> -the cause of the current scope is clear: J2SE Project are not designed to allow changes in bootclasspath.
This just could have been said in May.

> So the runtime bootclasspath is set using run.jvmargs=-Xbootclasspath/p:<something>. The project simply has no idea
that the user specified such a parameter. Not a defect, IMO. Contributions welcome.
Thanks, this makes it clear, why IDE can't know anything about right order of sources.

> -could you please point me to documentation that officially recommends this pattern to develop patches for OpenJDK? To
my knowledge, all OpenJDK projects are freeform projects (which, BTW, support bootclasspath changes).
I don't remember exactly, but for sure, they are freeform projects.

> I've tried to reproduce by adding an additional source folder in Tools -> Java Platforms to "Sources" tab of my JDK.
> Moving the new source folder to the top also moves it to the top in debugger's Sources window.
Yes, there is no problem in this scope, but the order between Java Platforms sources and the Project's sources seems to
be undetermined.
Comment 46 ulfzibis 2009-10-05 14:57:49 UTC
> There are obvious workarounds for this, e.g. make a copy of src.zip and add that copy instead of the original.
Thanks for this hint. But still difficult to manage without having issue 166801 solved.

> IMHO it's important that the debugger gets the ORDER of source roots correctly (matching execution order) and
> I believe that under such condition nobody wants to change the order of source roots.
I think we must distinguish 3 levels of source root order:
- the order inside the definition of Projects->Sources an Java_Platform->Sources
- the order inside the definition of Projects->Libraries
- the order outside between Java_Platform->Sources and Projects->Libraries

Comment 47 ulfzibis 2009-10-05 15:07:40 UTC
Created attachment 88846 [details]
Suitable order before starting debugger
Comment 48 ulfzibis 2009-10-05 15:25:50 UTC
Compare attachments 4 and 5:
What prevents us to generally set the JDK sources after the project's sources in order, instead of reordering them after
starting a debug session?

This solution would solve elegantly Ulf's problem.
Comment 49 Martin Entlicher 2009-10-09 09:42:06 UTC
After reading whole issue again and after playing with Ulf's project, I consider this particular issue as fixed - moonko
and jlahoda fixed passing of the correct JDK platform to debugger. - This was the regression introduced by CoS.

Since J2SE projects do not know anything about boot class path, debugger correctly puts all project's sources *after*
the platform sources. Which is a problem of projects defining -Xbootclasspath. This can solve only issue #166801.

The order listed in the last attached screenshot is actually wrong, I've noticed it and fixed just yesterday. So the
platform is always the first one now.

To solve problematic order of sources for projects with -Xbootclasspath we must fix issue #166801.

Comment 50 ulfzibis 2009-10-28 16:33:40 UTC
Note Issue 173310.
Comment 51 Quality Engineering 2011-07-29 14:10:17 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/693ed4ce2d6f
User: Jesse Glick <jglick@netbeans.org>
Log: 'platform.bootcp' will always be set after #165742.


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