Summary: | Segfault while loading project | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Daniel Santos <daniel.santos> |
Component: | Language Support: CPP (Clang-based) | Assignee: | kdevelop-bugs-null |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 5.1.1 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
backtrace -- stack overvflow? the address isn't < rsp but the stack trace goes on forever
project file .kdev4/gcc-git.kdev4 emerge --info on all deps of kdevelop unending stack trace |
Description
Daniel Santos
2017-07-27 00:58:55 UTC
Created attachment 106879 [details]
project file
Created attachment 106880 [details]
.kdev4/gcc-git.kdev4
Created attachment 106881 [details]
emerge --info on all deps of kdevelop
If you need to know anything else about my environment, I've included the emerge --info for all of kdeveop's dependencies via:
emerge --info dev-util/kdevelop $(for f in $(ldd /usr/bin/kdevelop | awk '{print $3}'); do qfile $f; done | awk '{print $1}' | sort -u)
I can't find a bug report with a similar backtrace from Upstream. Could you provide a bit more information? - Which project are you working on? Can you share? - Could you try to figure out which file KDevelop crashes on? The last lines of the debug output of kdevelop should tell you what it is currently parsing. (In reply to Kevin Funk from comment #4) > I can't find a bug report with a similar backtrace from Upstream. > > Could you provide a bit more information? > - Which project are you working on? Can you share? This is just the current HEAD of gcc: https://github.com/gcc-mirror/gcc > - Could you try to figure out which file KDevelop crashes on? The last lines > of the debug output of kdevelop should tell you what it is currently parsing. I didn't see output in stdout or stderr, do you mean in the backtrace? I admit I was surprised by the length of that and never got to the end of it. The file gcc-git.kdev4 has the list of files I excluded from the project so that the parser would only parse libs and archs that I was working on. It's running if I disable the parser, but KDevelop's parsing is something that I've always appreciated, even if it crashes sometimes. Please let me know if you are unable to reproduce and I'll try again. I have since rebuilt llvm and clang with -ggdb. I guess I'm supposed to repoen the bug after posting the info? Created attachment 106964 [details] unending stack trace (In reply to Kevin Funk from comment #4) > - Could you try to figure out which file KDevelop crashes on? The last lines > of the debug output of kdevelop should tell you what it is currently parsing. The stacktrace is unending (I finally interrupted it after 13000 frames that kept repeating) Ping. (In reply to Kevin Funk from comment #4) > - Could you try to figure out which file KDevelop crashes on? The last lines > of the debug output of kdevelop should tell you what it is currently parsing. By the way, I have not seen KDevelop give "debug output" that specifies what file it's parsing. I have build it with USE=debug (on Gentoo), so can you please be more specific about what mechanism is required to output this? Please try starting KDevelop in the terminal like this: QT_LOGGING_RULES="kdev*=true" kdevelop --ps (In reply to Kevin Funk from comment #9) > Please try starting KDevelop in the terminal like this: > QT_LOGGING_RULES="kdev*=true" kdevelop --ps Interesting, I tried running QT_LOGGING_RULES="kdev*=true" gdb --args kdevelop --ps and it didn't crash where it had before, but while parsing files it decided that it needed 18.5GiB of memory and I had to kill it. I'm running it now w/o gdb and I changed the number of parsing threads to 1 so as to be more certain of which file blew up and it's not failing yet nor eating much memory. I'll try this again tomorrow w/o the QT_LOGGING_RULES just to verify that I can still produce the error. Well here you go, this is at least one parse fail for upstream. This was w/o gdb so I don't have a backtrace, but I'll guess that clang had a stack overflow like gcc did prior to fixing it. I'm still not certain that this was the original failure, so I'll play more with it later. kdevplatform.language: creating parse-job "/home/daniel/proj/sys/gcc/git/gcc/testsuite/g++.dg/parse/stack1.C" new count of active parse-jobs: 1 Segmentation fault $ cat /home/daniel/proj/sys/gcc/git/gcc/testsuite/g++.dg/parse/stack1.C /* PR c/2161: parser stack overflow. */ /* { dg-do compile } */ #define ONE else if (0) { } #define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE #define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN #define THOU HUN HUN HUN HUN HUN HUN HUN HUN HUN HUN void foo() { if (0) { } /* 11,000 else if's. */ THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU } > "/home/daniel/proj/sys/gcc/git/gcc/testsuite/g++.dg/parse/stack1.C"
Yes, I feared something like this. KDevelop is attempting to parse one of GCC's unit tests. These are usually regressions tests for very bad compiler bugs. The libclang version you're using is probably not protected against this particular issue yet and will crash.
Note this is a pretty special issue, when working on any compiler code base. There are tons of source files for testing in them which will make any C++ parse go mad (think of "torture tests", etc.).
The only sane way to fix this is to ignore the whole testsuite/ folder by placing an empty .kdev_ignore in it (this will make KDevelop's background parser ignore everything below it). Please try and report back! (In reply to Kevin Funk from comment #13) > The only sane way to fix this is to ignore the whole testsuite/ folder by > placing an empty .kdev_ignore in it (this will make KDevelop's background > parser ignore everything below it). > > Please try and report back! Yes, that makes plenty of sense. For clang, I suppose it's a nice opportunity to leverage work done to produce tests for gcc. And quite frankly, having testsuite code parsed is not very valuable at all. Getting good parsing of the middle-end is, especially for somebody like me with no experience with data flow analysis, interprocedural constant propagation and such. I don't have this properly parsed yet, because of the quirk that gcc was converted to C++ a few years ago, but all of the file still end in .c. I believe I've found the fix in KDevelop for that, but I need to rebuild gcc (for build tree headers) and reparse. When I'm done with this, perhaps I should write a blog post about using KDevelop to work on gcc. But as for this bug, I still want to try to reproduce the crash I was having earlier to make sure that this is the full and correct work-around. I'll try to get back with you as soon as possible. Thanks! Daniel > When I'm done with this, perhaps I should write a blog post about using KDevelop to work on gcc. That'd be very much appreciated, make sure to notify us on e.g. kdevelop@kde.org or #kdevelop on Freenode. Thanks a lot! |