Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Firefox/3.5.2 Build Identifier: 20090920-1017 I have been trying to solve this issue for a while, and saw others on the web with the same issue but no bug report. I first thought the problem might be with the way the qt4 debugging package on ubuntu where done but after that problem having been fixed eclipse still hangs while debugging just an hello world qt app. However, the strange thing is if I compile the qt4 libraries myself and install it somewhere else than the normal /usr/bin /usr/lib and update the qt preference to use that qt installation instead of the default it works normally. Here is the setup: Qt 4.5.3 with qt plugin for eclipse 1.5.3 built for 4.5.3, gdb 4.3.3, eclipse started with vmargs of 4gb max memory on a machine with 8gb of memory. The error I get in the eclipse log is below !ENTRY org.eclipse.core.jobs 4 2 2009-10-09 10:56:24.817 !MESSAGE An internal error occurred during: "Launching HelloWorld". !STACK 0 java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.<init>(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at org.eclipse.core.runtime.Path.toPortableString(Path.java:959) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1843) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) at org.eclipse.cdt.debug.internal.core.model.CDebugTarget.getSourceLookupPath(CDebugTarget.java:1848) From the error log it perhaps seem to be in an infinite loop? Reproducible: Always Steps to Reproduce: 1.Use the sample qt hello world project 2.Try and debug the application 3.It hangs for a while then return with an application error gc limit exceeded
I'm going to fix the code to avoid a potential infinite recursion, but what I don't know is how you end up with such a recursion. Can you send a screenshot of the following things? - the launch configuration's Source tab. Please make sure to expand every node in the tree - Windows > Preferences > C/C++ > Debug > Common Source Lookup. Here, too, make sure to expand everything.
Created attachment 149252 [details] potential fix Not sure this addresses the problem, but this fix will at least prevent the theoretical infinite recursion that could occur of the same source container instance appears twice in the tree.
Committed to HEAD. Not marking this bug fixed as I don't know that this fixes the problem. It's a worth-while improvement to the logic, regardless.
Thanks for the quick reply and finally pointing me in the right direction. The folder in the source tab that was the problem was /usr/src. I didn't post a screenshot since as you can imagine on a dev machine there are many folder/files in there. I suppose that the qt plugin add by default <root>/src folder to the source path when /usr/lib /usr/include is given it adds /usr/src also automatically. That's why when I used another installation of the qt library in /usr/local/qt4local/lib for example the addition of /usr/local/qt4local/src didn't cause any problem. Perhaps it was not an infinite loop but just a very very long process? How much memory should this take? I have about 100k file in /usr/src in about 10k folders and i tried allocating 6GiB to eclipse and it still goes out of memory. If this is not a bug and it should take that much resources perhaps there should be a limitation by default of the number of file that is taken into account?
Well, the method is recursive so what may be happening is that we're blowing the the thread stack, not the heap. Try playing with the -Xss (Sun VM) switch and see if you can make the problem go away with a large enough number. That will tell us if the issue is that the recursion is just too deep. I could look at rewriting that method to not rely on recursion, but first I'd like to make sure that's indeed the issue.
I was under the impression that if the thread stack size would be the problem it would have been a stack overflow error... In any case I tried giving a 64MiB stack size and still out of memory error. However, I realized that there are some loop in the directory structure, I guess the debian kernel compilation scripts add some link in there that create infinite loops. Isn't there some detection algorithm in eclipse to detect that sort of thing? I guess your patch would fix the infinite loop? Perhaps adding an error message about the recursion would be good?
(In reply to comment #6) > I was under the impression that if the thread stack size would be the problem > it would have been a stack overflow error... In any case I tried giving a 64MiB > stack size and still out of memory error. However, I realized that there are > some loop in the directory structure, I guess the debian kernel compilation > scripts add some link in there that create infinite loops. Isn't there some > detection algorithm in eclipse to detect that sort of thing? I guess your > patch would fix the infinite loop? Perhaps adding an error message about the > recursion would be good? Ah, a filesystem link back to somewhere higher in the tree...that'll do it. My patch won't necessarily fix that scenario. I suspect there will be a unique ISourceContainer in your infinite tree. I'll see if I can reproduce the problem on Windows using links there (not sure if CDT supports them).
I did the test in the standard java environment and not cdt and the bug doesn't exist there, i.e. adding my /usr/src folder in the source tab doesn't cause hanging/out of memory error. Perhaps adapting their way of handling source code would provide a quick fix?
Created attachment 149371 [details] additional fix This fix should address the reported problem.
(In reply to comment #9) > Created an attachment (id=149371) [details] > additional fix > > This fix should address the reported problem. I will try and test the patch if possible before the next cdt release, would it be also possible to add an entry in the problem and/or log area with a warning or something similar? Thanks for the quick fix.
(In reply to comment #10) > (In reply to comment #9) > > Created an attachment (id=149371) [details] [details] > > additional fix > > > > This fix should address the reported problem. > > I will try and test the patch if possible before the next cdt release, would it > be also possible to add an entry in the problem and/or log area with a warning > or something similar? Thanks for the quick fix. I don't see a good vehicle for an error/warning. The error log should be reserved for reporting fundamental or internal things that have gone wrong, not for valid, but tricky, situations. In other words, there's nothing technically wrong with the user creating a tree that, via links, has a recursive path; the file system allows it, after all. CDT just needs to handle that situation gracefully.
