Bugzilla – Full Text Bug Listing
| Summary: | Indexer crashes Eclipse on code from www.boost.org | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Tomas Lidén <tomas.liden> | ||||||||
| Component: | cdt-core | Assignee: | Markus Schorn <mschorn.eclipse> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | cdtdoug, gheorghe, oleg.krasilnikov | ||||||||
| Version: | 3.0 | ||||||||||
| Target Milestone: | 4.0 RC4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux-GTK | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 26398 [details]
Code producing the crash - part 1
zip:ed tar file created with gtar cvfz
Created attachment 26399 [details]
Code producing the crash - part 2
I've found a workaround... By setting an exclusion filter on the source code (under C/C++ Project Paths, tab "Source") that excludes Optimization/Basic/Boost/boost/** the indexer will never try to index the code from boost.org, and the crash is avoided. However, the original problem is of course there... During my experimenting it seems that the indexer always crashes when working with variant.hpp and variant/**. Btw, my java -version says: java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia321420-20040626 (JIT enabled: jitc)) What do you mean by "crash Eclipse"? I'm assuming that you mean that Eclipse freezes or closes. I can't reproduce this in Windows but I'll give Linux/GTK a try. I get a ClassCastException with the CTags indexer that seems to halt the CTags indexer and prevents anything from going into the index. java.lang.ClassCastException: org.eclipse.core.internal.resources.Project at org.eclipse.cdt.internal.core.index.ctagsindexer.CTagsFileReader.parse (CTagsFileReader.java:85) at org.eclipse.cdt.internal.core.index.ctagsindexer.CTagsIndexAll.execute (CTagsIndexAll.java:115) at org.eclipse.cdt.internal.core.search.processing.JobManager.run (JobManager.java:466) at java.lang.Thread.run(Thread.java:534) I see several ClassCastExceptions with the boost source code with the full indexer (but no crash): java.lang.ClassCastException: org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTQualifiedName at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPFunctionTemplate.takesVarArgs (CPPFunctionTemplate.java:369) at org.eclipse.cdt.internal.core.index.domsourceindexer.IndexVisitorUtil.getParamet ers(IndexVisitorUtil.java:231) at org.eclipse.cdt.internal.core.index.domsourceindexer.CPPGenerateIndexVisitor.pro cessNameBinding(CPPGenerateIndexVisitor.java:316) at org.eclipse.cdt.internal.core.index.domsourceindexer.CPPGenerateIndexVisitor.pro cessName(CPPGenerateIndexVisitor.java:169) at org.eclipse.cdt.internal.core.index.domsourceindexer.CPPGenerateIndexVisitor.vis it(CPPGenerateIndexVisitor.java:112) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTName.accept (CPPASTName.java:90) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTQualifiedName.accept (CPPASTQualifiedName.java:175) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTDeclarator.accept (CPPASTDeclarator.java:126) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTFunctionDefinition.accept (CPPASTFunctionDefinition.java:92) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTemplateDeclaration.accept (CPPASTTemplateDeclaration.java:95) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTNamespaceDefinition.accept (CPPASTNamespaceDefinition.java:87) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTNamespaceDefinition.accept (CPPASTNamespaceDefinition.java:87) at org.eclipse.cdt.internal.core.dom.parser.cpp.CPPASTTranslationUnit.accept (CPPASTTranslationUnit.java:520) at org.eclipse.cdt.internal.core.index.domsourceindexer.DOMSourceIndexerRunner.inde xFile(DOMSourceIndexerRunner.java:133) at org.eclipse.cdt.internal.core.index.domsourceindexer.AbstractIndexerRunner.index (AbstractIndexerRunner.java:76) at org.eclipse.cdt.internal.core.index.cindexstorage.Index.add (Index.java:110) at org.eclipse.cdt.internal.core.index.domsourceindexer.DOMAddCompilationUnitToInde x.indexDocument(DOMAddCompilationUnitToIndex.java:29) at org.eclipse.cdt.internal.core.index.domsourceindexer.DOMAddFileToIndex.execute (DOMAddFileToIndex.java:60) at org.eclipse.cdt.internal.core.search.processing.JobManager.run (JobManager.java:466) at java.lang.Thread.run(Thread.java:534) Try running Eclipse with more virtual machine memory: ./eclipse -vmargs -Xmx512M This should fix your problem with the full indexer. It's because you are working with such a large project that you need to have more memory reserved for the virtual machine than default. Created attachment 26418 [details]
bandaid for this PR (for CTags)
I'm not sure why the fileName is "" and this patch is probably just a bandaid
to the problem. When applied, the CTags index for the attached project goes
from 0 IEntryResults and 0 files indexed to 55350 IEntryResults and 2862 files
indexed with this patch for CTags.
It also fixes the ClassCastException.
Sorry, increasing the memory does not help for me (I've tried 1024M as well).
The full indexer still crashes (again the last file mentioned is variant.hh).
By "crashing" I mean that I get the following:
Unrecoverable Stack Overflow: addr=b7351ddf, ee=b20aed10, er=b21e2b00
JVMDG217: Dump Handler is Processing a Signal - Please Wait.
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written
to /users/liden/javacore.20050825.093552.11117.txt
JVMDG215: Dump Handler has Processed Exception Signal 11.
Do you want the core file?
Sometimes I also get a stack that starts with:
java.lang.IllegalArgumentException:
at
org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java(Inlined
Compiled Code))
at
org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java(Inlined
Compiled Code))
at
org.eclipse.core.runtime.Path.removeFirstSegments(Path.java(Compiled Code))
at
org.eclipse.cdt.make.internal.core.scannerconfig.gnu.ScannerInfoConsoleParse
rUtility.translateRelativePaths
(ScannerInfoConsoleParserUtility.java:219)
at
org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCScannerInfoConsolePa
rser.processSingleLine(GCCScannerInfoConsoleParser.java:138)
at
org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsolePa
rser.processLine(AbstractGCCBOPConsoleParser.java:118)
at
org.eclipse.cdt.internal.core.ConsoleOutputSniffer.processLine(ConsoleOutput
Sniffer.java:178)
...
(Now I will try the CTags bandaid..)
I gave up regarding the bandaid, since it requires me to get the source code, patch and rebuild the appropriate CDT parts - too much work for me... For us this is a rather serious problem - hoping to hear more from you soon! I have started looking at this and have a couple of questions. First, what is part1 and what is part2 in the attachments. I tried running ctags on part1 and had no problem. Am I doing something wrong? I had to upload all the code in two parts, since bugzilla has a limit on 2Mb for attachments. (If you were able to run on part1, that might be another indication on something fishy about variant.hh (which is in part2)). I do get an StackOverflowError using the FullIndexer in 4.0, the FastIndexer works fine. I'll try to fix this. That's nice.. But due to this bug and the lack of support for local CVS I gave up on Eclipse and CDT long ago - now using good old Xemacs as the rest of the team.. Fixed in 4.0 > 20070619. |
I will attach a tar-file with some of our base classes. It also includes a large number of files from boost.org. If you remove the library Basic/Boost, everything works fine, but when you include it the (full) indexer will crash Eclipse with a java-core. When running with the CTags indexer you get the following stack: java.lang.ClassCastException: org.eclipse.core.internal.resources.Project at org.eclipse.cdt.internal.core.index.ctagsindexer.CTagsFileReader.parse (CTagsFileReader.java(Compiled Code)) at org.eclipse.cdt.internal.core.index.ctagsindexer.CTagsIndexAll.execute (CTagsIndexAll.java:115) at org.eclipse.cdt.internal.core.search.processing.JobManager.run (JobManager.java:466) at java.lang.Thread.run(Thread.java:567)