Whenever I start a new class I get a crash, this seems to fix it, I'm
not sure if it's the correct fix.
Details
- Reviewers
apol
Diff Detail
- Repository
- R32 KDevelop
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
Can you show us the example code that crashes? We'll need to write a unit test. And I wonder why we'd ever not get a context. Maybe when the AST is completely broken/empty?
Odd, never seen this and I've certainly created new classes...
- Ctrl+O a file to create a new one and call it milianisawesome.h or .cpp.
- Paste the copyright header from another file (because that's obviously how you do it :D).
Type something after (like #include or something, you won't get to finish the word). What's worse, you will restart kdevelop and you'll get an empty file. Then you'll add the copyright again and boom. Etc.
I cannot reproduce this. What version of clang do you have? Can you create a file with kate or similar and run duchainify on it - does it also crash? If so, please paste that file. Also, please show a backtrace. I really wonder what's going on for you here. I've done what you describe multiple times in the last ~year or so that I'm using kdev-clang and it never crashed for me...
Meh, I can't reproduce now. I'll leave this open until I can again.
I'm running on Arch's clang 3.7.0, but I've had this issue ever since I moved to kdev-clang, months ago. I can't recall if it was every time or what.
ok, marking the review for now. if you find a way to reproduce this, please add the steps required here. I'm not opposed to landing this patch, but it should have a unit test accompanying it.
Whoops, guys.
I committed a similar fix just yesterday:
commit 9fdd73059dc191db733414ae577658e23ed51306 Author: Kevin Funk <kfunk@kde.org> Date: Sat Nov 28 16:42:14 2015 +0100 Fix potential SEGV (as seen on CI) ==29050==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x7f26e12e0cf5 sp 0x7f269f092520 bp 0x7f269f092530 T19) #0 0x7f26e12e0cf4 in KDevelop::TopDUContext::parsingEnvironmentFile() const /home/jenkins/builds/kdevplatform/stable-kf5-qt5/language/duchain/topducontext.cpp:550 #1 0x7f26ad42110c in parsingEnvironmentFile /home/jenkins/builds/kdevelop/stable-kf5-qt5/languages/clang/clangparsejob.cpp:151 #2 0x7f26ad424990 in ClangParseJob::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) /home/jenkins/builds/kdevelop/stable-kf5-qt5/languages/clang/clangparsejob.cpp:321 #3 0x7f26d3af5a6a in ThreadWeaver::IdDecorator::run(QSharedPointer<ThreadWeaver::JobInterface>, ThreadWeaver::Thread*) /home/jenkins/builds/threadweaver/stable-kf5-qt5/src/iddecorator.cpp:69
ClangHelpers::buildDUChain may return a nullptr, so we definitely have to protect against this IMO...
ok, then we can close this request. odd that we could not reproduce it locally but apparently there is a unit test then :D