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.

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...