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.
Summary: | [67cat] Wrong debug sources | ||
---|---|---|---|
Product: | debugger | Reporter: | ulfzibis <ulfzibis> |
Component: | Java | Assignee: | issues@debugger <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dstrupl, jlahoda, mentlicher, mmirilovic, moonko |
Priority: | P2 | Keywords: | REGRESSION |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 167153 | ||
Bug Blocks: | |||
Attachments: |
Wrong debug sources
Sorry, does NOT WORKFORME. So I still have to add the right sources manually and deal with Issue 166801. Simply reproduced in recent dev build (imported favourite+toolbar+platform settings from 6.7.1) Wrong order of debug sources even on normal debug, JDK/scr.zip should be last Suitable order before starting debugger |
Description
ulfzibis
2009-05-21 19:13:22 UTC
Created attachment 82580 [details]
Wrong debug sources
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. <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. Marking as P2 because it's a regression. fixed. Can we have this for Hotfix 1 aka 6.7.1 ? 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 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. 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. > 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. > 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. > 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.
Created attachment 84787 [details]
Sorry, does NOT WORKFORME. So I still have to add the right sources manually and deal with Issue 166801.
Correction: Seems that debugger steps into right source, but "sources" window display is wrong. *** Issue 168511 has been marked as a duplicate of this issue. *** 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. 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. I finally managed to reproduce it - the compile on save must be enabled, otherwise it work fine 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. 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. 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 Reassigning all moonko's java/source bugs to myself. Reproduced in fresh standard Java project. See: Issue 171169. 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. Created attachment 87502 [details]
Simply reproduced in recent dev build (imported favourite+toolbar+platform settings from 6.7.1)
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 Aha, it is about debugging *test*. Should be fixed now: http://hg.netbeans.org/jet-main/rev/e6d94018a804 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. Created attachment 87508 [details]
Wrong order of debug sources even on normal debug, JDK/scr.zip should be last
It remains wrong order of debug sources even on normal debug, which results in same problem, a little different way. 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. After Jan's fix this is no longer P2. Making it P3. 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. The use case (to modify JDK classes and put them on bootclasspath) is not really common. Making this P3 again. 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. 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). 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 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. Also, please, try both variants with "Compile on Save" on and off. Thanks. 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). 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. 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. Set breakpoint to java.nio.charset.Charset1.lookup() and then advance by Step Over. Last comment belongs to Issue 173405, sorry. 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. > 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 Created attachment 88846 [details]
Suitable order before starting debugger
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. 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. Note Issue 173310. 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. |