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.
While testing Rainier we found problems if we anabled modules after a debug session had been started. We discovered we had the same problems debugging Java with NetBeans 3.5.1. Here is how to reproduce two of the problems: Problem #1: empty debugger views after a module has been turned on/off ---------------------------------------------------------------------- 1) use NetBeans 3.5.1 2) start Netbeans 3) step into any Java program and verify the debugger views are working. 4) finish the session (Finish) 5) turn off for instance the Welcome Screen module (any module does the same thing) 6) step into the same program as before. Now the views are empty. Problem #2: erratic debugger behavior after a module has been turned on/off ------------------------------------------------ 1) use NetBeans 3.5.1 2) start Netbeans 3) step into any Java program and verify the debugger views are working. 4) turn off for instance the Welcome module (any module will do) without stopping the debugger first. 5) do a Step Over, and the debugger throws the following exception: Annotation: Exception occurred in Request Processor java.lang.NullPointerException at org.netbeans.modules.debugger.support.actions.StepOverAction.performAction(StepOverAction.java:58) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:69) at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:97) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:328) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:670)
Looks like a BIG problem, not only in debugger. I discoverred that default lookup content is released when any module is enabled / disabled.
Hanz could you elaborate on what "default lookup content is released" means?
I assume that: Lookup.getDeafault (). lookup (Debugger.class) == Lookpu.getDefault (). lookup (Debugger.class) -> Lookup keeps (weak reference probably) returned instances. It works if user does not install / uninstall modules. But it returns a new instance after some changes in set of installed modules.
The actual bug in openide/lookup is now recorded as serious issue 38420. This one may or may not be blocked by it, as there is probably another solution to the actual debugging problem.
Dulplicate to 38420. *** This issue has been marked as a duplicate of 38420 ***
Fixing issue #38420 might provide a solution to this bug (hasn't been tried yet), but anyway there is probably something wrong in debuggercore. Assuming that Lookup.getDefault().lookup(X.class) always returns the same instance is *not* safe. You may either 1. Always call Lookup afresh when you need to know the instance. So you get some instance of X, which you use. Normally it will be the same one each time. 2. Call lookup(new Lookup.Template(X.class)) and store the Lookup.Result; you can cache the results, for example, but you then need to listen to changes and invalidate the cache. Issue #38420 is a bug only insofar as it may be unnecessarily recreating object instances which would be optimized a bit. The semantic bug is in the debugger, however.
Assuming that a fix for #38420 would solve the symptoms of this bug.
Another simple fix would be to use META-INF to register instances instead of layer file.
....which would be a good idea anyway, since META-INF/services is generally preferred for singleton services. Simpler and more efficient.
Thank you guys for your help. I do not want to switch to META-INF/services, because I have no guarantee that it will work in some longer period. I will try to find some other solution.
"I do not want to switch to META-INF/services, because I have no guarantee that it will work in some longer period." - huh? I don't understand what you're talking about.
Do not try to understand Jesse, this is just Hanz's personal style. He would safe more energy by implementing your suggestion, yet he will rather blame others...
Jesse: Its not specified in Lookup documentation, that it can be used as singleton. So, I do not want to use it that way. I thought that it is guaranteed, but it is not true for some implementations in some specific cases. Its not problem to use some other solution. Yarda: Do not waste time for fixing ;)
This has been fixed by fixing the Issue #38420, I cannot reproduce it anymore.
Good to know, but please still spend some time on implementing suggestion to use use META-INF to register instances instead of layer file which would be a good idea anyway, since META-INF/services is generally preferred for singleton services. Simpler and more efficient.
Please, could you verify if your problem is fixed. Thanks.
I cannot verify the fix for another week or two. I need to verify it in a Sun Studio build and we're (kind of) between releases right now. We're in the process of sending a list of issues we need resolved for Mercury to CDP. This will be on that list. But we haven't even created our branch yet so there is no branch for the fix to be back ported to yet. Once the branch exists and the fix has been back-ported I will be able to verify the fix. I won't be able to verify the fix in the trunk for some time though.
Reopening because this issue will be on our Mercury must-fix list we're giving to CDP.
Verified as working on trunk builds.
Milan, should not we close this issue then?
Don't know, see comment from Gordon. Maybe they want to fix it in some branch.
Yes. We will need it fixed in a branch which will be created (probably) later this week. The branch tag will be "release35M".
The release35M branch has been created. Please port the fix to this branch at your convenience (but if its going to be a while, please let me know).
See Gordon's comments.
See whole discussion above for a proper fix for release 3.5. For example "Another simple fix would be to use META-INF to register instances instead of layer file."
fixed in release35M branch I have used static variable to cahe pointer to DebuggerCoreImpl. I am not able to test it regulary - I do not know how to create a regular build from that branch, but it should be OK. cvs commit -m "38249: Debugging breaks if enable/disable any modules" Register.java (in directory E:\Dev\release35M\debuggercore\src\org\netbeans\modules\debugger\) Checking in Register.java; /cvs/debuggercore/src/org/netbeans/modules/debugger/Attic/Register.java,v <-- Register.java new revision: 1.14.36.1.6.1; previous revision: 1.14.36.1 done
Please back out this fix. It has caused various other P1 problems
After integrated "fixes" from debuggercore of issus 38249, here are the problems found indetails : I. For current debugging session a toggle bpt get error msg "Can not set breakpoints until the program has been loaded in the debugger" b Able to set bpt from dbx console, bpt node shows correctly in bpt view, but no annotation shows in source editor. c Unable to set bpt from [Debug]->[New Breakpoint...] menu, no response. d [Rerun Process] button does not work, beeps if clicked. e Other buttons works OK. f Bpts/Local/Watch/Stack/Thread/Session/Properties views work OK. II. For new loaded debugging session a No "Start New Session" popup dialog. b new session did not show in Session view. c Bpts/Local/Watch/Stack/Thread/Properties views did not switch to new session. d Multiple set of tabs in Output window. e No node shows in Session/Stack/Local/Thread views f watch node created from [New Watch] button shown as >No session< in name colume. OK with watch nodes in Watch view/Properties sheet if created from dbx console (display command) g OK with toggle-bpts/annotation/bpts-view h Source editor shows new source for newly loaded session. i NPE when clicking on StepOver/Cont/StepOut/Fix buttons. j StepInto/RuntoCursor buttons got grey out. k Clinking on [Finish Session] button does not have response. After debugging into codes in dbxgui/debuggercore for problem I.a, and found the 'currentDebugger' in org.netbeans.modules.debugger.delegator.DelegatingDebugger.getCurrentDebugger() is always null after turn on/off modules, before turning on/off modules it has valid value. the codes in dbxgui that calls DelegatingDebugger.getCurrentDebugger() look like this: public static DbxDebugger getCurrentDebugger() { Debugger coreDebugger = (Debugger) Lookup.getDefault().lookup(Debugger.class); Debugger debugger; if (coreDebugger instanceof EnterpriseDebugger) { debugger=((EnterpriseDebugger)coreDebugger).getCurrentDebugger(); if (debugger instanceof DbxDebugger) { return (DbxDebugger) debugger; } } return null; } Hope these infos would help to address problem better
fixed in nb36 & nb40.
Can someone back port the fix to 3.5V ? The next release (vulcan) of sunstudio is based on 3.5V.
Not possible, the fix is nb40 specific. For nb36 - this problem was fixed in core module, and fix is not isolated. NOt possible to backport to nb35. In nb40 - this code has been rewritten completely.
Then I need the versions of source file changes in 3.6 core that fixed this issue, I'll back port to 3.5V myself.
You should ask Jarda Tulach (jtulach) for this diff in this case. This bug has been fixed (workarrounded) in openide module for nb36. But again, I think that to fix in not portable to 35.
No such exception nor empty debugger views have been witnessed recently. Closing.