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 209476 - Deadlock in IDE
Summary: Deadlock in IDE
Status: RESOLVED WONTFIX
Alias: None
Product: javaee
Classification: Unclassified
Component: Expression Language (show other bugs)
Version: 7.1
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Martin Fousek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-12 14:57 UTC by adrianriley
Modified: 2016-07-07 08:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
jstack listing (38.07 KB, text/plain)
2012-03-12 14:57 UTC, adrianriley
Details

Note You need to log in before you can comment on or make changes to this bug.
Description adrianriley 2012-03-12 14:57:39 UTC
Created attachment 116614 [details]
jstack listing

Deadlock in IDE, see attached stack listing
Comment 1 Petr Somol 2012-03-13 08:43:14 UTC
Please evaluate.

The attachment contains:

Found one Java-level deadlock:
=============================
"org.netbeans.lib.editor.codetemplates.AbbrevDetection":
  waiting for ownable synchronizer 0x146e2828, (a java.util.concurrent.locks.ReentrantLock$FairSync),
  which is held by "Parsing & Indexing Loop (201112071828)"
"Parsing & Indexing Loop (201112071828)":
  waiting to lock monitor 0x0836546c (object 0x16bc7978, a org.netbeans.modules.web.el.ResourceBundles),
  which is held by "ToolTip-Evaluator"
"ToolTip-Evaluator":
  waiting for ownable synchronizer 0x146e2828, (a java.util.concurrent.locks.ReentrantLock$FairSync),
  which is held by "Parsing & Indexing Loop (201112071828)"
Comment 2 Tomas Zezula 2012-03-15 08:38:36 UTC
The ResourceBundles.getBundles calls JS.runUserActionTask while holding a private lock.
The problem is that it both calls the JS.runUserActionTask (tries to acquire the parser lock) and is called under the parser lock (it's called by a task registered by task factory and executed by "Parsing & Indexing Loop").
I suggest to split the synchronization in the ResourceBundles.getBundles.
Comment 3 Marek Fukala 2012-04-26 09:29:52 UTC
ResourceBundles.getBundles() and .getBundlesHashCode() don't have to be synchronized at all - removed.

But .getBundlesMap() synchronization is necessary since it tests a cached value and possibly recreates the cache. Unfortunately the method can be indirectly called from any thread so it may or may not hold the parsing lock. Inside .getBundlesMap() .getBundles() is called which may require the parsing lock.

So to me the only solution seems to be to acquire the parsing lock before entering the synchronization inside .getBundlesMap(). I reckon this may be quite inefficient since the method may be called very frequently. Another solution may be setting a condition for any code accessing the ResourceBundles methods to hold the parsing lock.

Tome, can you please look at the problem again and possibly help me? I'm not sure what should be the proper solution here.
Comment 4 Martin Balin 2016-07-07 08:52:36 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss