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 251398 - IDE locked when hints changed
Summary: IDE locked when hints changed
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 8.1
Hardware: PC Other
: P2 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: THREAD
Depends on:
Blocks:
 
Reported: 2015-03-24 14:20 UTC by Jiri Skrivanek
Modified: 2015-04-03 09:11 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump. (44.65 KB, text/plain)
2015-03-24 14:20 UTC, Jiri Skrivanek 		Details
Proposed changes (1.43 KB, patch)
2015-03-25 09:44 UTC, Svata Dedic 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2015-03-24 14:20:08 UTC 
Created attachment 152816 [details]
Thread dump.

Several threads are locked (see attached thread dump) and I am not sure which one is the culprit. Please, try to evaluate. I did:

- create java project
- added lines to main class

        for (int i = 0; i < 10; i++) System.out.println("aaa");
        if (true) System.out.println("aaa");

- open Tools, Options, Editor, Hints
- tick Braces
- click Apply
- click OK. Then scanning started and IDE was locked.

Product Version: NetBeans IDE Dev (Build 1)
Java: 1.8.0_40; Java HotSpot(TM) 64-Bit Server VM 25.40-b25
Runtime: Java(TM) SE Runtime Environment 1.8.0_40-b26
System: Windows 8 version 6.2 running on amd64; Cp1250; en_US (nb)
Comment 1 Milutin Kristofic 2015-03-24 14:55:36 UTC 
Reproducible for me. I am looking for the culprit
Comment 2 Ondrej Vrabec 2015-03-24 15:12:31 UTC 
could it be svata's changes in at org.openide.filesystems.Repository.getLocalRepository(Repository.java:415) ?
Comment 3 Svata Dedic 2015-03-24 16:07:09 UTC 
I think I "just" helped the issue to surface by introducing additional default Lookup lookup. IMHO the FolderOrder should not hold the instance lock while writing to the filesystem (= dispatching lower-layer events under higher-layer lock).
Comment 4 Svata Dedic 2015-03-25 09:43:19 UTC 
Please see the proposed patch. I don't believe the issue is fixable in Repository.getLocalRepo or FileUtil.getConfigFile - the Provider must be looked up all the time. Some caching (i.e. do not lookup instance for the previously used Lookup) could help in Netbeans IDE, but would not solve the bug in general.

I've however noticed that the deadlock is caused by some observer on the order reacting in the middle WHILE the lock on FolderOrder is still held. The FolderOrder code indicates that all the field changes are already done, and the lock is held just in order to prevent simultaneous setOrders to damage file attributes (so the order setOrder write will be eventually locked out).

I think that doing the FS mutations in FS.AtomicAction will postpone listener reactions so it will effectively break the deadlock, while the potential concurrent FOrder.write() will be still locked out.

See + review the attached patch, please.
Comment 5 Svata Dedic 2015-03-25 09:44:48 UTC 
Created attachment 152836 [details]
Proposed changes
Comment 6 Jaroslav Havlin 2015-03-25 11:53:24 UTC 
The evaluation is very reasonable, and the patch seems fine to me.
Thank you, Svata.
Comment 7 Svata Dedic 2015-03-25 13:33:16 UTC 
Will be fixed in jet-main#ae0e0d5f9a02
Comment 8 Quality Engineering 2015-03-27 03:23:12 UTC 
Integrated into 'main-silver', will be available in build *201503270001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/ae0e0d5f9a02
User: Svata Dedic <sdedic@netbeans.org>
Log: #251398: FolderOrder delays FS events until after sync lock is released