Bug 201282 - IDE hang when saving a Maven project
IDE hang when saving a Maven project
Product: xml
Classification: Unclassified
Component: XAM
PC Windows 7
: P3 (vote)
: 7.2
Assigned To: Svata Dedic
Depends on:
Blocks: 85405 197208
  Show dependency treegraph
Reported: 2011-08-24 15:08 UTC by _ gtzabari
Modified: 2015-09-17 13:21 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

thread-dump (32.66 KB, application/octet-stream)
2011-08-24 15:09 UTC, _ gtzabari
messages.log (185.39 KB, application/octet-stream)
2011-08-24 15:09 UTC, _ gtzabari

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2011-08-24 15:08:37 UTC
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.
Comment 1 _ gtzabari 2011-08-24 15:09:07 UTC
Created attachment 110181 [details]
Comment 2 _ gtzabari 2011-08-24 15:09:55 UTC
Created attachment 110182 [details]
Comment 3 _ gtzabari 2011-08-24 15:10:56 UTC
When I say "hang" I mean the UI stopped repainting.
Comment 4 Jesse Glick 2011-08-24 19:12:12 UTC
Looks like a flaw in the workaround for bug #197208.
Comment 5 Jesse Glick 2011-08-24 19:39:08 UTC
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.
Comment 6 Martin Balin 2015-09-17 13:21:17 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo