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.
Product Version: NetBeans IDE Dev (Build 201108190601) Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b17 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb) User directory: C:\Users\g.tzabari\.netbeans\dev Cache directory: C:\Users\g.tzabari\.netbeans\dev\var\cache I got an IDE hang while saving Project Properties on a Maven project. I'm going to attach a thread-dump and messages.log for your review. CPU usage remained at 5% but the CPU sampler didn't pick up any obvious activity so I think it was just the GC at work.
Created attachment 110181 [details] thread-dump
Created attachment 110182 [details] messages.log
When I say "hang" I mean the UI stopped repainting.
Looks like a flaw in the workaround for bug #197208.
My understanding of at java.lang.Object.wait(Object.java:503) at org.netbeans.modules.xml.xam.AbstractModel.startTransaction(AbstractModel.java:404) - locked <0x19888358> (a org.netbeans.modules.maven.model.pom.impl.POMModelImpl) at org.netbeans.modules.xml.xam.AbstractModel.startTransaction(AbstractModel.java:379) at org.netbeans.modules.maven.hints.pom.StatusProvider$StatusProviderImpl$3.run(StatusProvider.java:160) is that there is a race condition, which looks like it should be rare. isIntransaction returns false, but then immediately afterwards startTransaction blocks, implying that another thread has since started a transaction. StatusProvider intentionally does not attempt to start a fresh transaction when there already is one, but in this case it is fooled. The isIntransaction method is inherently prone to race conditions, it seems, unless you are sure to only call it from the same thread as started the transaction. What is needed is a variant of startTransaction which never blocks and which just returns false immediately if a transaction was already in progress; this would not be prone to the race condition. Catching and ignoring InterruptedException is also a bad idea; it means the calling thread cannot be interrupted except using Thread.stop! (Which means that standard deadlock recovery techniques may fail to unfreeze the IDE.) The current sT should just return false if interrupted, I think. As to other workarounds, I do not see any good options. Bug #197208 prevents StatusProvider from first acquiring the XAM transaction lock and then PM.mutex. And the implementation of bug #85405 (CustomizerDialog.actionPerformed) always acquires PM.mutex before notifying listeners, but in this case it is the listener (CustomizerProviderImpl.OptionListener) which is responsible for finishing the XAM transaction.
Report from old NetBeans version. Due to code changes since it was reported likely not reproducible now. Feel free to reopen if happens in 8.0.2 or 8.1.