Bugzilla – Full Text Bug Listing
| Summary: | Indexer crashes during build of LLVM + Clang | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Jeff Sember <jeffeclipsebug> | ||||||
| Component: | cdt-indexer | Assignee: | Markus Schorn <mschorn.eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Markus Schorn <mschorn.eclipse> | ||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | cdtdoug, malaperle, yevshif | ||||||
| Version: | 8.0.1 | ||||||||
| Target Milestone: | 8.1.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 364225, 364226 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jeff Sember
Created attachment 207242 [details]
Log file from index operation
I'm assuming you are using 8.0.1 since you installed a "fresh" Eclipse with a build id of 20110916-0149. Is that right? (About > Installation Details) How much memory did you try in eclipse.ini (-Xmx)? My Macbook just died but I'll test on Windows. I'm not very familiar with llvm/clang, are you trying to build both the source contained in llvm-2.9.tgz and clang-2.9.tgz in a single project? Or everything in svn trunk? I have both llvm and clang in a single project on Windows and I get the errors. The ClassCastException and the NullPointerException are definitely bugs. For the OutOfMemoryError, see bug 280196. I'm not sure about the StackOverflowError yet. For the NPE, I isolated the code and opened bug 364225. I'll try to do the same for the ClassCastException and StackOverflowError. Opened bug 364226 for the ClassCastException. About the StackOverflowError, it occurs because of a huge number of compound statements.
void foo()
{{{ ...... many more ...... }}}
Maybe the parser could abort when reaching a certain number of compound statements and warn instead of triggering a StackOverflowError. But I don't know what that number would be.
(In reply to comment #2) > I'm assuming you are using 8.0.1 since you installed a "fresh" Eclipse with a > build id of 20110916-0149. Is that right? (About > Installation Details) The id for both C/C++ Development Tools and C/C++ Development Tools SDK is: 8.0.0.201109151620 > How much memory did you try in eclipse.ini (-Xmx)? My Macbook just died but > I'll test on Windows. I have the following settings in my eclipse.ini file: -Xms500m -Xmx500m I believe I actually tried it with a higher value, 600m or even 800m, before setting it back to 500m; there was no improvement. > I'm not very familiar with llvm/clang, are you trying to > build both the source contained in llvm-2.9.tgz and clang-2.9.tgz in a single > project? Or everything in svn trunk? To simplify things, after posting the bug report, I tried installing LLVM without the Clang subproject. I also told the CMake program to omit the 'tests' and 'examples' subprojects. Now I think the indexing completes without hanging, though there are still some errors reported in the log file. I can prepare a new bug report (or at least provide more details) for this simplified scenario if you like. (In reply to comment #6) > I can > prepare a new bug report (or at least provide more details) for this simplified > scenario if you like. Can you attach a log file that contains the new errors? Thanks! (In reply to comment #7) > Can you attach a log file that contains the new errors? Thanks! Hi Marc-Andre, Attached is the log file. It's only showing the one problem now. As mentioned earlier, this build omits both the example and test components. Created attachment 207386 [details]
Log file after removing clang, llvm:tests, and llvm:examples
Log file indicates only a single crash
(In reply to comment #8) > (In reply to comment #7) > > Can you attach a log file that contains the new errors? Thanks! > > Hi Marc-Andre, > > Attached is the log file. It's only showing the one problem now. As mentioned > earlier, this build omits both the example and test components. I'm pretty sure the error is the same NPE as in bug 364225. I think that covers everything, thank you Jeff! (In reply to comment #5) > About the StackOverflowError, it occurs because of a huge number of compound > statements. > > void foo() > {{{ ...... many more ...... }}} > > Maybe the parser could abort when reaching a certain number of compound > statements and warn instead of triggering a StackOverflowError. But I don't > know what that number would be. Markus, do you think it would be worthwhile to add a limit to the number of compound statements? I wasn't sure if I should create a bug for that. (In reply to comment #11) > (In reply to comment #5) > > About the StackOverflowError, it occurs because of a huge number of compound > > statements. > > > > void foo() > > {{{ ...... many more ...... }}} > > > > Maybe the parser could abort when reaching a certain number of compound > > statements and warn instead of triggering a StackOverflowError. But I don't > > know what that number would be. > Markus, do you think it would be worthwhile to add a limit to the number of > compound statements? I wasn't sure if I should create a bug for that. When the stack overflow occurs, the indexer skips the file causing it. So, the stack overflow already aborts the parser when the nesting becomes too deep. I don't see how a fixed limit would improve this behavior. With the current treatment, the user can increase the stack size (e.g: -Xss1m) to allow for deeper nestings. (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #5) > > > About the StackOverflowError, it occurs because of a huge number of compound > > > statements. > > > > > > void foo() > > > {{{ ...... many more ...... }}} > > > > > > Maybe the parser could abort when reaching a certain number of compound > > > statements and warn instead of triggering a StackOverflowError. But I don't > > > know what that number would be. > > Markus, do you think it would be worthwhile to add a limit to the number of > > compound statements? I wasn't sure if I should create a bug for that. > > When the stack overflow occurs, the indexer skips the file causing it. So, > the stack overflow already aborts the parser when the nesting becomes too > deep. I don't see how a fixed limit would improve this behavior. You're right. Resolving. |