Community
Participate
Working Groups
Build Identifier: 20110916-0149 That's a report of freezing issue mentioned in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=361220. My current CDT version id 8.0.0.201109151620. But this happened months (or years) before release of CDT 8.0. I have three open projects in Eclipse. These are C++ Makefile projects. Two of these projects have 'true' command set as their build command (that is nothing is done) and third actually built with 'make'. I edit files of all these three projects while I'm working. It happens after some time spent using eclipse and building and rebuilding projects (using "Project->Build all"). This time it took almost 3 hours to start reproducing. What happens: at some point while using Eclipse I open Project explorer and click a file in it and Eclipse freezes. It does not react to clicks or any keyboard input and utilizes 25% CPU of a quad core computer (i.e. uses 100% of a single core). It continues for several minutes then Eclipse continues working until I do some clicking in Project Explorer again, which leads to another freeze. These freezes seem to occur when I have a file selected in one project and then I click a file in another project. If at this time I switch console from "CDT build console" used by default to "CDT Global build console" clicking any files in project explorer does not cause freezes anymore. I didn't try to switch back to "CDT build console" to check whether freezes start to happen again, will do next time I have it. Also clearing build consoles (the one with a lot of output seem to be enough) seem to fix the issue, but I have to double check it. Attaching Eclipse thread dumps made while it was unresponsive. Reproducible: Always Steps to Reproduce: 1. Work for some long time with several projects open, rebuilding them from time to time. 2. Click files of different projects in Project Explorer 3. At some point Eclipse start to freeze after these clicks.
Created attachment 205513 [details] Thread dump 1. Made soon after eclipse froze
Created attachment 205514 [details] Thread dump 2. 40 seconds later
Created attachment 205515 [details] Thread dump 3. Another 40 seconds later
Also all these projects are under source control. We use SVN through Subclipse plug-in. It is not these three projects specific issue. It happens on other combinations of other projects too.
Could it be that the build output contains _very_ long lines? The StyledText renderer can become rather inefficient in this case. See also bug 318036.
Now I got this issue within minutes after restarting Eclipse (and two project rebuilds). Freezes seem to happen when I have a file from a project with 'true' build command selected and then I click a file from a project with 'make' build command. Any other clicking sequence does not cause a freeze (at least right now). And clearing build console of a project with 'make' build command removes freezes.
Anton Leherbauer, yes right now linker's command line is almost 11500 characters long, and in other projects we have linker's command lines up to 32K characters long (more than 32K does not get executed by Windows properly, so we have to jump through hoops to fit into that limit). Are there any workarounds?
(In reply to comment #7) > Anton Leherbauer, yes right now linker's command line is almost 11500 characters > long, and in other projects we have linker's command lines up to 32K characters > long (more than 32K does not get executed by Windows properly, so we have to > jump through hoops to fit into that limit). > > Are there any workarounds? As far as workaround, you could add '@' sign in the beginning of the line in linker command in makefile to prevent make (if you use make) from printing it in output. 11500 character line probably is not that readable anyway.
The linker is called from a deep dark depths of a makefiles from an SDK we are building against. And I prefer not to touch it with a 10 feet stick: it's a whole mess there. And somehow it does not happen when "CDT Global build console" is active, so I believe long lines can be processed in reasonable time.
