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.
The problem is nicely hidden in AbstractLookup There is a boolean flag that should never be true when it is checked, but it was. The AbstractLookup is serializable and 1. the flag is not marked transient 2. the writeObject is not synchronized So it can happen that the serialization occur while one of the guarded methods is running and the flag gets serialized as true. From that on, every subsequent IDE startup will fail with the exception as the flag is true.
Created attachment 9424 [details] Exception
I'm assuming this is not really P1 unless it happens consistently.
Assume can be fixed by just changing: private boolean usingTree; to private transient boolean usingTree; in AbstractLookup.java.
I considered it P1 because once it happens, it prevents successfull startup and keeps happening on all subsequent tries (until you delete proper file in userdir/cache). I came along it by frequently restarting the IDE. Adding transient modifier would help with this problem, but it may be better to add proper synchronization around writeObject as we don't want to serialize inconsistent lookup, do we?
I suppose. This is jtulach's and dstrupl's code, I do not pretend to understand it. No opinion on priority, QA can decide.
Created attachment 9429 [details] Possible patch (untested)
QA - is this a showstopper P1? AFAIK this is the first time it has been reported. But of course if it happens (and you don't know the simple workaround) it is a big problem.
I agree with Petr -- it's a P1. If there is the slightest chance this could happen in real life, then it's even worse than a simple data loss. The user may not be able to figure out how to start the IDE again. I suppose that without making a change to respective file in the userdir, even re-installing the IDE will not help.
"I suppose that without making a change to respective file in the userdir, even re-installing the IDE will not help." - actually updating any module will kill the cache and make the problem disappear. But of course you cannot update a module without starting the IDE unless you're clever enough to know about the better workaround anyway. :-) Petr - any hints on how to reproduce this, since you seem to be the only person to run across it?
Created attachment 9432 [details] Another untested patch; also include robustness fix against other such possible bugs
I was doing some startup measurements, so I just frequently started the IDE. It happened to me several times and on two different machines (@work: SPARC/Solaris, 360MHz, @home: Celly/Linux, 1130MHz) There just needs to be some ongoing lookup query when the save occurs and the query can it fact hang on I/O, so it can have some duration... On the other hand, I can't provoke it now when I'm trying hard.
Better. Apply it. When I wrote the original patch for serialiation of Lookup the useLookup field was not there yet so I could not make it transient...
Applied to trunk. committed Up-To-Date 1.29 openide/src/org/openide/util/lookup/AbstractLookup.java
Merged. committed Up-To-Date 1.28.2.1 openide/src/org/openide/util/lookup/AbstractLookup.java
Seems OK now.