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 50369 - deadlock
Summary: deadlock
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P1 blocker (vote)
Assignee: Daniel Prusa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-13 16:49 UTC by Jan Jancura
Modified: 2007-09-26 09:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Deadlock (16.10 KB, text/plain)
2004-10-13 16:53 UTC, Jan Jancura
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Jancura 2004-10-13 16:49:46 UTC
Deadlock during editing file.
Comment 1 Jan Jancura 2004-10-13 16:53:53 UTC
Created attachment 18269 [details]
Deadlock
Comment 2 Martin Matula 2004-10-13 23:24:20 UTC
The problem seems to be that DefaultLangModel.doFire starts MDR
transaction and then transitively tries to lock Children.MUTEX, which
is illegal. Dane, can the transaction locking be removed from
DefaultLangModel.doFire? Or does wrapping of the transaction by
Children.MUTEX (so that it is locked first) make better sense?
Comment 3 Daniel Prusa 2004-10-14 10:07:33 UTC
I have removed mdr transaction from DefaultLangModel.doFire. This
transaction was added as a part of fix of issue 46345 and seems to be
redundant.
Emane, can you confirm that the change has not an impact on tests
(that it does not cause a deadlock in the javasrc tests on your
machines) ?


Checking in DefaultLangModel.java;
/cvs/java/src/org/netbeans/modules/java/bridge/DefaultLangModel.java,v
 <--  DefaultLangModel.java
new revision: 1.7; previous revision: 1.6
Comment 4 ehucka 2004-10-18 13:01:13 UTC
The tests seem right, no deadlock there.
Comment 5 Jiri Prox 2005-07-12 13:33:04 UTC
Honzo, can you verify this issue, please? Thanks.