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 - deadlock on opening shell file
Summary: deadlock on opening shell file
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: Settings (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords: ERGONOMICS, RANDOM, THREAD
Depends on: 169844
Blocks:
  Show dependency tree
 
Reported: 2009-03-05 18:36 UTC by Vladimir Voskresensky
Modified: 2009-08-05 00:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
deadlock (36.08 KB, text/plain)
2009-03-05 18:36 UTC, Vladimir Voskresensky 		Details
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 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