Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365308

Summary: Eclipse hangs when adding an "output location" filter
Product: [Tools] CDT Reporter: Thomas . <spam-receiver>
Component: cdt-coreAssignee: Project Inbox <cdt-core-inbox>
Status: RESOLVED NOT_ECLIPSE QA Contact: Doug Schaefer <cdtdoug>
Severity: critical    
Priority: P3 CC: aleherb+eclipse, malaperle
Version: 8.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Thread Dump generated with JVisualVM none

Description Thomas . CLA 2011-12-01 08:54:10 EST 
Build Identifier: 20110615-0604

For whatever reason there is a task "Searching for Binaries (<project>)" in my "Progress" view. This task is running forever without ever ending.

I posted a thread to the Eclipse forum and a reply pointed me to "Project Properties -> C/C++ General -> Paths and Symbols -> Output Location". The goal was to inhibit the "Search for Binaries" by applying a filter here.

Reproducible: Always

Steps to Reproduce:
1. Have an Eclipse project, where the task "Searching for Binaries" is running infinitely.
2. Add filter "*" to output location "<project name>" (i.e. the only entry in the "output locations" list.
3. Click apply.
Comment 1 Thomas . CLA 2011-12-01 08:56:20 EST 
Created attachment 207786 [details]
Thread Dump generated with JVisualVM

Thread dump taken when Eclipse was hanging (i.e. hourglass, not-responding UI, white menu bar).
Comment 2 Marc-André Laperle CLA 2011-12-01 12:23:01 EST 
I can't reproduce that with a simple project. Is it a big project?
Comment 3 Thomas . CLA 2011-12-01 15:02:27 EST 
(In reply to comment #2)
> I can't reproduce that with a simple project. Is it a big project?

I would say so: appr. 20000 source files; C, C++, Pascal, Java, Shell etc.

The task "Sarching for Binaries" always is stuck on the same file, and it was stuck when I created the thread dump. "Stuck" here means that the task is visible in the "progress" view and the progress indicator keeps running through the bar without any percentage. When I pres the "cancel" button for this task, the "(cancel requested)" appears, but it actually never cancels. Furthermore, when I close Eclipse, it seems to close normally. But when I later logoff from the computer, Windows tells me that a "SWT_Window_Eclipse" cannot be closed--whatever window that is...
Comment 4 Thomas . CLA 2011-12-01 15:39:49 EST 
Cor(In reply to comment #3)
> (In reply to comment #2)
> > I can't reproduce that with a simple project. Is it a big project?
> 
> I would say so: appr. 20000 source files; C, C++, Pascal, Java, Shell etc.
>
Correction: It's about 20,000 C/C++ files and 55,000 files in total incl. various other languages, resources etc.
Comment 5 Anton Leherbauer CLA 2011-12-02 02:41:11 EST 
The thread dump does not indicate a deadlock.  The binary search job seems to be stuck at

   java.lang.Thread.State: RUNNABLE
	at java.io.FileInputStream.readBytes(Native Method)
	at java.io.FileInputStream.read(Unknown Source)
	at org.eclipse.cdt.internal.core.model.CModelManager.createBinaryFile(CModelManager.java:701)
	at org.eclipse.cdt.internal.core.model.BinaryRunner$Visitor.visit(BinaryRunner.java:220)
	at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:65)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:82)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
	at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127)
	at org.eclipse.core.internal.resources.Resource.accept(Resource.java:75)
	at org.eclipse.cdt.internal.core.model.BinaryRunner$1.run(BinaryRunner.java:122)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)


Is the file it is trying to read from special in some way? Is it on a remote share? Can it be opened in a text editor?
Comment 6 Thomas . CLA 2011-12-02 07:57:17 EST 
(In reply to comment #5)
> The thread dump does not indicate a deadlock.  The binary search job seems to
> be stuck at
> 
>    java.lang.Thread.State: RUNNABLE
>     at java.io.FileInputStream.readBytes(Native Method)
>     at java.io.FileInputStream.read(Unknown Source)
>     at
> org.eclipse.cdt.internal.core.model.CModelManager.createBinaryFile(CModelManager.java:701)
>     at
> org.eclipse.cdt.internal.core.model.BinaryRunner$Visitor.visit(BinaryRunner.java:220)
>     at
> org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:65)
>     at
> org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:82)
>     at
> org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
>     at
> org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86)
>     at
> org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127)
>     at org.eclipse.core.internal.resources.Resource.accept(Resource.java:75)
>     at
> org.eclipse.cdt.internal.core.model.BinaryRunner$1.run(BinaryRunner.java:122)
>     at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> 
> 
> Is the file it is trying to read from special in some way? Is it on a remote
> share? Can it be opened in a text editor?

Well, yes. Further investigation shows: 
The file in question is hosted on a ClearCase Windows mount. Unlike similar files in the same folder, the specific file cannot be opened on Windows (Explorer, CC Explorer, Eclipse etc.). The same file is accessible via the respective Unix ClearCase mount.

Thus, the problem is specific to the file. However, on a lower priority maybe this could be addressed by a timeout supervision or so?
Comment 7 Anton Leherbauer CLA 2011-12-02 08:20:47 EST 
(In reply to comment #6)
> Thus, the problem is specific to the file. However, on a lower priority maybe
> this could be addressed by a timeout supervision or so?

We cannot protect all occasions where we read from a file by some timeout policy. That's overkill.