Community
Participate
Working Groups
Build Identifier: 20110916-0149 Eclipse UI hangs at saving a file for about a minute. Windows tells that Eclipse doesn't respond. When handing, Eclipse sometimes writes "Updating duplicate <file name>" in its status line. Project source files are stored on a remote server with Samba. Is that possible to determine the cause of the problem? Is it due to bad network drive performance, or dur to some Eclipse bug? Reproducible: Sometimes Steps to Reproduce: 1. Just save a file (I work on cpp projects) and sometimes it happens. 2. 3.
> 1. Just save a file (I work on cpp projects) Moving to CDT for initial investigation. Please attach some stack traces.
Please see http://wiki.eclipse.org/How_to_report_a_deadlock for how to create a JVM thread dump.
Created attachment 208523 [details] dump made in eclipse console when eclipse was hanging at saving a file
Thanks for the dump. The main thread is blocked by the reconciler thread which is in some deeply nested loop filling the ResourceLookupTree cache. This is likely a consequence of slow filesystem access and a large project tree. Not sure if there is much we can do to accommodate slow file systems.
(In reply to comment #4) > Thanks for the dump. > The main thread is blocked by the reconciler thread which is in some deeply > nested loop filling the ResourceLookupTree cache. > > This is likely a consequence of slow filesystem access and a large project > tree. > Not sure if there is much we can do to accommodate slow file systems. Yes, the project is large. But why saving one file causes such a problem? Is ResourceLookupTree stored on disk?
(In reply to comment #5) > Yes, the project is large. But why saving one file causes such a problem? Is > ResourceLookupTree stored on disk? The ResourceLookupTree is built to work around platform issues in resolving absolute paths to eclipse resources. In general this operation is fairly quick. A potential reason for why it takes too long is that the JVM is running low on free memory on the heap. How much free heap memory does the JVM have, when you run into this issue?
(In reply to comment #6) > (In reply to comment #5) > > Yes, the project is large. But why saving one file causes such a problem? Is > > ResourceLookupTree stored on disk? > > The ResourceLookupTree is built to work around platform issues in resolving > absolute paths to eclipse resources. In general this operation is fairly quick. > A potential reason for why it takes too long is that the JVM is running low on > free memory on the heap. > How much free heap memory does the JVM have, when you run into this issue? I ran eclipse with default eclipse.ini. Heap size can be found in the first attachement with stack traces. Then I have added a line -Xmx1024m (I guess it's bigger than default size?) to eclipse.ini file and the very first attempt to save a file caused eclipse to hang for 15 - 20 seconds. Please find heap size dump and eclipse.ini attached.
Created attachment 208724 [details] eclipse.ini with -Xmx1024m
Created attachment 208725 [details] heap size dump
(In reply to comment #8) > Created attachment 208724 [details] > eclipse.ini with -Xmx1024m The file contains two -Xmx arguments, I think the last one wins. To see how much free heap memory you have you can select the eclipse preference 'General/Show heap status'. Information about the heap will then be shown in the status bar.
(In reply to comment #10) > (In reply to comment #8) > To see how much free heap memory you have you can select the eclipse preference > 'General/Show heap status'. Information about the heap will then be shown in > the status bar. 122M/335M
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #8) > > To see how much free heap memory you have you can select the eclipse preference > > 'General/Show heap status'. Information about the heap will then be shown in > > the status bar. > 122M/335M This looks ok, so heap memory is not the issue. Initializing the ResourceLookupTree does not access the file system, therefore a slow file-system should not have an effect. When the IDE is stuck, does it use a lot of CPU? When you create another stack-trace a couple of seconds later, can you still see that the ResourceLookupTree is being initialized?
Created attachment 209360 [details] two dumps made within 5 seconds
> When the IDE is stuck, does it use a lot of CPU? It uses 20%, idle system uses 5% > When you create another stack-trace a couple of seconds later, can you still see that the ResourceLookupTree is being initialized? I attached two dumps made within 5 seconds. As fas as I can see, both dumps have deep ResourceLookupTree stacks.
(In reply to comment #14) Thanks. To me it looks like the resource tree is really huge. I will add a tracing option, which tells us how large the tree is and an option to turn off the workaround for the lookup.
I have added a tracing option to see how much time is consumed for building up the lookup tree. The lookup tree provides features above what the platform can do for us, therefore I cannot provide an option to turn it off. To trace your application you need to use the command line option: -debug <options-file> Put the following in the options file: # turns on tracing for the cdt-core plugin org.eclipse.cdt.core/debug=true # Reports statistics for building the structure to do resource lookups. org.eclipse.cdt.core/debug/resourceLookup=true
No response from submitter.
*** cdt git genie on behalf of Markus Schorn *** Bug 366570: Added tracing option. [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=e85390856ae703d30b56d9cb557bae61e2893327
