Bug 201282 - IDE hang when saving a Maven project
IDE hang when saving a Maven project
Status: NEW
Product: xml
Classification: Unclassified
Component: XAM
7.1
PC Windows 7
: P3 (vote)
: 7.2
Assigned To: Svata Dedic
issues@xml
: RANDOM, THREAD
Depends on:
Blocks: 85405 197208
  Show dependency treegraph
 
Reported: 2011-08-24 15:08 UTC by _ gtzabari
Modified: 2011-10-18 13:19 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


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

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]
thread-dump
Comment 2 _ gtzabari 2011-08-24 15:09:55 UTC
Created attachment 110182 [details]
messages.log
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.


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