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.
Build: NetBeans IDE 6.0 Beta 1 (Build 200709141330) VM: Java HotSpot(TM) Client VM, 1.6.0_02-b06 OS: Windows XP, 5.1, x86 User Comments: trying to set options; tools/options
Created attachment 49941 [details] stacktrace
/cvs/core/options/src/org/netbeans/modules/options/OptionsPanel.java,v <-- OptionsPanel.java new revision: 1.58; previous revision: 1.57
Build: NetBeans IDE Dev (Build 200710240532) VM: Java HotSpot(TM) Client VM, 1.6.0_03-ea-b02 OS: Windows XP, 5.1, x86 User Comments: just Tool >Options>Miscellaneous^J^J-maybe I removed too much clusters from etc/netbeans.clusters ? But the IDE works w/o problems
Created attachment 51700 [details] stacktrace
There are more instances of this since this was closed. See statistics URL -- in my case (43080), had to restart IDE. Have not been able to reproduce though.
Build: NetBeans IDE 6.1 Beta (Build 200803050202) VM: Java HotSpot(TM) Client VM, 1.5.0_12-b04 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 59601 [details] stacktrace
Created attachment 59762 [details] stacktrace
Reassigning to new module owner jskrivanek.
Build: NetBeans IDE 6.1 (Build 200804211638) VM: Java HotSpot(TM) Client VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02 OS: Linux, 2.6.24-16-generic, i386 User Comments: I was viewing the "Advanced Options", then clicked "Basic Options"
Created attachment 61092 [details] stacktrace
This should not happen anymore because Advanced Options were removed from IDE.
Happened to me today. P2 because I cannot access Tools > Options > Miscellaneous (I can see only blank panel). Product Version: NetBeans IDE Dev (Build 101129-e5fa9d201a2b) Java: 1.6.0_22; Java HotSpot(TM) 64-Bit Server VM 17.1-b03 System: Linux version 2.6.36 running on amd64; UTF-8; cs_CZ (nb)
Created attachment 104013 [details] diff for KWalletProvider This is a patch to fix KWalletProvider. Comments are welcome. Will be integrated in a week.
Upps, wrong bug number. Attachment was intended for http://netbeans.org/bugzilla/show_bug.cgi?id=186196
Can't reproduce. Looks like a threading issue but the real cause is not clear yet. It's too risky to try to fix it close to CF. Will add some debugging info to trunk and wait for the next reproduction on the dev builds to understand the cause of such behaviour.
Maybe init() has not been called? AdvancedPanelController.getComponent() looks wrong: getAdvancedPanel().init(); return getAdvancedPanel (); where getAdvancedPanel() is unsynchronized. If it is possible for calls to be made from non-EQ threads, this provides a race condition. Say thread T1 calls getLookup(), which goes into getAdvancedPanel(), sees advancedPanel=null, and starts to create it. Now T2 calls getComponent(), which also sees advancedPanel=null, creates an AdvancedPanel #1, and sets the field to it; getComponent calls init() on AdvancedPanel #1. Now T1 finishes getAdvancedPanel(), sets the advancedPanel field to AdvancedPanel #2, and returns from getLookup(). T2 then calls getAdvancedPanel() again, which is now #2 - uninitialized! - and returns it. Simplest fix would just be to synchronize getAdvancedPanel(). Another change which would be desirable anyway is to getComponent(): AdvancedPanel p = getAdvancedPanel(); p.init(); return p; Also, AdvancedPanelController.update() calls getAdvancedPanel().update() without calling init() on it; and AdvancedPanel.update() assumes init() has been called. So if this were called without getComponent() having been called earlier, there would be an NPE. Not sure whether that is possible.
Created attachment 106900 [details] Calling init from constructor might be even simpler fix
(In reply to comment #18) > Calling init from constructor might be even simpler fix Would be simpler, though there might be some performance cost to it; I guess the original intent was to avoid creating the (nontrivial) Swing components unless and until the panel is displayed.
Thank you for the comments. Jesse, your guess about calling getLookup() from another thread looks like the right one. I haven't made design of this module out yet but looks like CategoryModel.masterLookupTask could be the place where getAdvancedPanel() is called from non-EQ thread. So attaching the patch you suggested, please take a look. As for your guess that AdvancedPanelController.update() can be called without getComponent() having been called earlier, it was my first thought so I checked the code carefully. getComponent() is always called earlier than update() method so not the case.
Created attachment 106916 [details] AdvancedPanelController patch
Patch looks right to me.
So, marking the bug as 70_HR_FIX_CANDIDATE and integrating fix into core-main
Fix: http://hg.netbeans.org/core-main/rev/6c3fbacf72d3
Can someone from QA test, please? The best way to test is to open Tools > Options > Miscellaneous in stressful conditions (during building big projects etc.)
Integrated into 'main-golden', will be available in build *201103120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6c3fbacf72d3 User: Yulia Novozhilova <ynov@netbeans.org> Log: Fix #117384: NPE at org.netbeans.modules.options.advanced.AdvancedPanel.update
I tested it a little bit and was not able to reproduce it in latest dev build.
I have also tested it on 7.0 RC2 (Build 201104070000) and was unable to reproduce it.