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.

Bug 201282

Summary:	IDE hang when saving a Maven project
Product:	xml	Reporter:	_ gtzabari <gtzabari>
Component:	XAM	Assignee:	Svata Dedic <sdedic>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	jglick
Priority:	P3	Keywords:	RANDOM, THREAD
Version:	7.1
Hardware:	PC
OS:	Windows 7
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:
Bug Blocks:	85405, 197208
Attachments:	thread-dump messages.log

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.

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.