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 203508 - Read lock held open on build.xml
Summary: Read lock held open on build.xml
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 7.1
Hardware: All All
: P2 normal (vote)
Assignee: Jesse Glick
URL:
Keywords: PERFORMANCE
: 201007 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-11 13:12 UTC by J Bachorik
Modified: 2011-11-14 16:47 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 181883

Attachments
nps snapshot (10.05 KB, application/nps)
2011-10-11 13:12 UTC, J Bachorik 		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 J Bachorik 2011-10-11 13:12:17 UTC 
This bug was originally marked as duplicate of bug 186348, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE Dev (Build 20111011-dfcb3e627c5f)
VM: OpenJDK 64-Bit Server VM, 20.0-b11, OpenJDK Runtime Environment, 1.6.0_23-b23
OS: Linux

User Comments:
yardus: Editing build.xml in a freeform project



Maximum slowness yet reported was 4018 ms, average is 4018
Comment 1 J Bachorik 2011-10-11 13:12:26 UTC 
Created attachment 111851 [details]
nps snapshot
Comment 2 Jaroslav Tulach 2011-10-12 07:13:52 UTC 
There is an open input stream blocking getOutputStream. Probably somebody forget to close it and it waits for finalization (but I don't see the close of inputstream in the snapshot at all).
Comment 3 Petr Jiricka 2011-10-14 15:34:43 UTC 
This problem looks rather serious (I mean the aspect that I can't save the file) - I could not find any workaround, not even restarting the IDE. Basically, I can not edit this build.xml in the IDE.
Comment 4 Jesse Glick 2011-10-14 20:20:29 UTC 
There is an input stream open on build.xml but there is no way from the log file to tell where that is, so there is no way to know what code is actually responsible. (Does masterfs record this information in a way that the diagnostics could be better?)

Is there a particular build.xml that this always happens with? Any other information to reproduce?
Comment 5 Jesse Glick 2011-10-14 20:21:35 UTC 
More meaningful summary. The GUI freeze is just a side effect of there being a read lock (and of SaveAction being called in EQ).
Comment 6 Jesse Glick 2011-10-14 20:54:34 UTC 
I think MutualExclusionSupport should hold a stack trace when assertions are enabled, adding the lock owner(s) as a root cause to any IOException it throws.
Comment 7 Jesse Glick 2011-10-18 15:02:20 UTC 
Finally found a (temporarily) reproducible case, and managed to add useful diagnostics.
Comment 8 Jesse Glick 2011-10-18 15:04:07 UTC 
f3a8eecb1dbd seems to have been responsible.
Comment 9 Jesse Glick 2011-10-18 15:09:26 UTC 
core-main #2183ba37266d
Comment 10 Quality Engineering 2011-10-19 14:14:04 UTC 
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/2183ba37266d
User: Jesse Glick <jglick@netbeans.org>
Log: #203508: Read lock held open on build.xml
Comment 11 Jesse Glick 2011-11-14 16:47:05 UTC 
*** Bug 201007 has been marked as a duplicate of this bug. ***