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
Alias: None
Product: editor
Classification: Unclassified
Component: Settings (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vitezslav Stejskal
Depends on: 169844
  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:

deadlock (36.08 KB, text/plain)
2009-03-05 18:36 UTC, Vladimir Voskresensky

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 ( 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]
Comment 2 Vladimir Voskresensky 2009-03-05 18:37:54 UTC
sorry, 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(!?).

- 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

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 (upload may still be in progress)
User: Vita Stejskal <>
Log: #159714: seems like when modules are enabled Lookup.Result changes may be delivered twice (recursively), which in this case caused a deadlock