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.
070608. Stack trace in OW had two links in it. Clicked on second, nothing happened, exception.
Created attachment 43481 [details] Stack trace
*** Issue 113446 has been marked as a duplicate of this issue. ***
I think there must be a flaw in our WeakSet implementation. 1. One WeakSet is created, statically at class init time. All accessed to it are synchronized (with itself as a monitor). 2. Every Hyperlink object adds itself to this set when constructed. Nothing is ever removed explicitly - only when collected. 3. Hyperlink objects are immutable in most fields, and do not override equals or hashCode. 4. Once in a blue moon, probably under heavy threading conditions, this assertion is thrown, at which time: a. The this object is still live, since methods are being called on it from the output window. b. set.contains(this) reports true. c. Yet, set.toString() does not list this as a member. d. And iterating over the set does not produce this.
It shouldn't be a race condition, everything is properly synchronized and the WeakSet does nothing asynchronously itself. It looks like some corruption of inner state, where iterChain doesn't match entries. I suspected that it may be related to the fact that Entry.remove() clears its chain fields, while iterator might want to follow them, but I couldn't find a scenario that might lead to calling remove on an Entry while it is tracked by the iterator. How reproducible is this? CCing Yarda, he may enjoy an attempt to formally proof the correctness.
A race between normal execution and the garbage collector, I meant. Not reproducible at all - has been observed a few times. If there are some assertions added to WeakSet, they will probably show something within the next few months.
*** Issue 115950 has been marked as a duplicate of this issue. ***
Build: NetBeans IDE 6.0 Beta 2 (Build 200710212201) VM: Java HotSpot(TM) Client VM, 1.6.0_02-b05 OS: Linux, 2.6.11-1.1369_FC4smp, i386 User Comments: compiling
Build: NetBeans IDE 6.0 RC2 (Build 200711201000) VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 53440 [details] stacktrace
Build: NetBeans IDE 6.0 RC2 (Build 200711201000) VM: Java HotSpot(TM) Client VM, 1.5.0_07-87 OS: Mac OS X, 10.4.11, i386 User Comments: Clicking on a error in output window.
Created attachment 53611 [details] stacktrace
Build: NetBeans IDE 6.0 (Build 200711261600) VM: Java HotSpot(TM) Client VM, 1.6.0-b105 OS: Windows XP, 5.1, x86 User Comments:
Created attachment 54399 [details] stacktrace
Build: NetBeans IDE 6.0 (Build 200711261600) VM: Java HotSpot(TM) 64-Bit Server VM, 1.6.0_03-b05 OS: Linux, 2.6.22-14-generic, amd64 User Comments:
Created attachment 55603 [details] stacktrace
Created attachment 55604 [details] stacktrace
Build: NetBeans IDE 6.0 (Build 200711261600) VM: Java HotSpot(TM) Client VM, 10.0-b19 OS: Windows Vista, 6.0, x86 User Comments:
Created attachment 55888 [details] stacktrace
This issue has already 20 duplicates
Frequent enough it needs to be solved, I think. Would be simple to work around in the Ant module but if WeakSet is truly wrong, many other modules could be affected in unknown ways.
Nejedlák mentioned to me that the problem is caused by incorrect use of memory barriers. However thinking about it, that would mean there needs to be at least two threads accessing the WeakSet. If that was the case then, my proposed fix would be to add note to javadoc about this class being single threaded and close as wontfix. Jesse, can you guarantee your instance is always accessed only from one thread? If it is not true, we should probably try hard to find the problem, as if it is not caused by wrong memory barriers, it shall be reproducible. So we should at least add some logging into the implementation to move processing of this bug a bit forward.
I cannot see how the hyperlinks field in this class: http://hg.netbeans.org/main/file/9a81a620e198/o.apache.tools.ant.module/src/org/apache/tools/ant/module/run/Hyperlink.java could be accessed by more than one thread; after its creation, all accesses are within a block synchronized on it. Obviously the removal of elements by garbage collection would happen in another thread.
Yes, there are at least two threads all the time, the user thread and the garbage collector. And no amount of java-level synchronization could prevent gc thread from clearing the "reference" field of Reference classes. Only a strong reference can, but I haven't found a scenario where would WeakSet depend on a field not backed by a strong reference.
pnejedly can't work on this anymore, passing to issues@core now, as I don't know who maintains openide utilities now. I guess waiver candidate for 6.1?
Tomas will evaluate. Reassigning.
As Jesse assumed there was an error in WeakSet. Problem was that when new element was inserted there was a check (in chainIntoIter()) if referent of next entry in iter. chain is null. If so, it was removed. However, this removed entry remained in ReferenceQueue and after next checkRefQueue() its remove() was called once again which set set.iterChain to null and disconnected all elements in WeakSet from iteration chain (while remaining in hash map - so they could be found, but not iterated). Solution is to call remove() only from checkRefQueue() or to add additional check to Entry.remove(). Fix+test: http://hg.netbeans.org/core-main/rev/1b56e3ebb462 or http://hg.netbeans.org/main/rev/1b56e3ebb462