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 159714

Summary: deadlock on opening shell file
Product: editor Reporter: Vladimir Voskresensky <vv159170>
Component: SettingsAssignee: Vitezslav Stejskal <vstejskal>
Status: RESOLVED FIXED    
Severity: blocker CC: jtulach
Priority: P2 Keywords: ERGONOMICS, RANDOM, THREAD
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 169844    
Bug Blocks:    
Attachments: deadlock

Description Vladimir Voskresensky 2009-03-05 18:36:00 UTC
opened cnd.kit and some other cnd modules.
after a long java development tried to open shell file (i18n-check.sh) from Project view => long running dialog appeared
and IDE was frozen forever.
Ctrl+/ shows deadlock
Comment 1 Vladimir Voskresensky 2009-03-05 18:36:51 UTC
Created attachment 77779 [details]
deadlock
Comment 2 Vladimir Voskresensky 2009-03-05 18:37:54 UTC
sorry, i18n-check.sh I opened from cnd.kit in Files view, not Project view
Comment 3 Jaroslav Tulach 2009-03-09 17:51:31 UTC
I guess something is wrong in editor.settings. They deadlock with themselves and preferences(!?).

at org.netbeans.modules.editor.settings.storage.StorageImpl$Filters.rebuild(StorageImpl.java:505)
at org.netbeans.modules.editor.settings.storage.StorageImpl$Filters.access$400(StorageImpl.java:456)
at org.netbeans.modules.editor.settings.storage.StorageImpl$Filters$1.resultChanged(StorageImpl.java:491)
- locked <0x00007f18a4e04b28> (a java.util.HashMap)

maybe the subsequent events shall not be fire under the "HashMap" lock?
Comment 4 Vitezslav Stejskal 2009-03-10 15:58:37 UTC
Ok, I assume this can't be reproduced reliably.
Comment 5 Vitezslav Stejskal 2009-03-20 08:59:19 UTC
http://hg.netbeans.org/jet-main/rev/2d55987a312a

Should work now. Jardo, could you please have a closer look at the first stacktrace involved in the deadlock (the one
for 'Default RequestProcessor' thread)? IMO this is actually bug in Lookup. Here is the situation:

1. I have Lookup.Result and LookupListener listening to changes in this result
2. An event arrives and the listener queries the result for allInstances
3. the allInstances query causes another (the same?) event to arrive again recursively, which in this case makes the
same recalculation happen again and ends up with firing my own event from inside a synchronized section, hence the deadlock

I fixed it in my LookupListener, but maybe something is wrong in Lookup itself. Not sure. Also this situation sounds
specific for ergonomics and probably does not normally happen. Anyway, just wanted to let you know...
Comment 6 Quality Engineering 2009-03-21 08:33:08 UTC
Integrated into 'main-golden', will be available in build *200903210201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2d55987a312a
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #159714: seems like when modules are enabled Lookup.Result changes may be delivered twice (recursively), which in this case caused a deadlock