Bug 159714 - deadlock on opening shell file
deadlock on opening shell file
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Settings
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
: ERGONOMICS, RANDOM, THREAD
Depends on: 169844
Blocks:
  Show dependency treegraph
 
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
:


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

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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo