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
trying to set options; tools/options
Created attachment 49941 [details]
/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
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]
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
Created attachment 59601 [details]
Created attachment 59762 [details]
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
I was viewing the "Advanced Options", then clicked "Basic Options"
Created attachment 61092 [details]
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:
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();
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]
Patch looks right to me.
So, marking the bug as 70_HR_FIX_CANDIDATE and integrating fix into core-main
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)
User: Yulia Novozhilova <email@example.com>
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.