How to fix “Xcode quit unexpectedly while using the libclang.dylib plug-in.”?

I have this every time in a short while after I start xCode (5.1.1).

Removed user data, turned off source control (as some posts suggested), no effect, still crashes (while showing Indexing… that never finishes). Even reinstalled xCode, without any effect, still says the same.

  • Autolayout constraints warning “Will attempt to recover by breaking constraint” (possible logic issue)
  • UIViewController Freeform size issue
  • Provisioning Profiles in XCode 5
  • iOS- Provisioning profile issues.
  • NSClassFromString() always returns nil
  • Build target randomly added to Xcode scheme
  • Did anybody fixed such an xCode?

    enter image description here

    Here’s the crashing thread:

     Thread 7 Crashed:: Dispatch queue: IDEIndex PCH Creation Lock
        0   libclang.dylib                  0x00000001080c60d9 void llvm::BitstreamWriter::EmitRecordWithAbbrevImpl<unsigned long long>(unsigned int, llvm::SmallVectorImpl<unsigned long long>&, llvm::StringRef) + 809
        1   libclang.dylib                  0x00000001080c5867 void llvm::BitstreamWriter::EmitRecord<unsigned long long>(unsigned int, llvm::SmallVectorImpl<unsigned long long>&, unsigned int) + 71
        2   libclang.dylib                  0x00000001081e9f25 clang::ASTWriter::WriteASTCore(clang::Sema&, llvm::StringRef, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, clang::Module*) + 35045
        3   libclang.dylib                  0x00000001081e160e clang::ASTWriter::WriteAST(clang::Sema&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, clang::Module*, llvm::StringRef, bool) + 6830
        4   libclang.dylib                  0x00000001080719a3 clang::ASTUnit::Save(llvm::StringRef) + 691
        5   libclang.dylib                  0x0000000107fe974f clang_saveTranslationUnit + 543
        6      0x0000000106ac63af -[IDEIndexClangTranslationUnit cxTranslationUnit] + 331
        7      0x0000000106c2c11a +[IDEIndexClangDataSource translationUnitForPCHFile:arguments:session:create:] + 259
        8      0x0000000106cf5552 __90-[IDEIndex createPCHFile:arguments:hashCriteria:target:session:willIndex:translationUnit:]_block_invoke + 1739
        9   libdispatch.dylib               0x00007fff957012ad _dispatch_client_callout + 8
        10  libdispatch.dylib               0x00007fff95702166 _dispatch_barrier_sync_f_invoke + 39
        11      0x0000000105fce5cf -[DVTDispatchLock performLockedBlock:] + 95
        12      0x0000000106cf4932 -[IDEIndex createPCHFile:arguments:hashCriteria:target:session:willIndex:translationUnit:] + 919
        13      0x0000000106ac4985 -[IDEIndexClangDataSource generateDataForJob:] + 1274
        14      0x0000000106ac42fb -[IDEIndexDataSource processJob:] + 147
        15      0x0000000106ac3e33 +[IDEIndexingEngine runFileJob:] + 732
        16      0x0000000106ac3550 -[IDEIndexingJob run] + 161
        17      0x0000000106c3233c __40-[IDEIndexingJobScheduler _scheduleJobs]_block_invoke + 33
        18  libdispatch.dylib               0x00007fff957041d7 _dispatch_call_block_and_release + 12
        19  libdispatch.dylib               0x00007fff957012ad _dispatch_client_callout + 8
        20  libdispatch.dylib               0x00007fff9570309e _dispatch_root_queue_drain + 326
        21  libdispatch.dylib               0x00007fff95704193 _dispatch_worker_thread2 + 40
        22  libsystem_pthread.dylib         0x00007fff8ead7ef8 _pthread_wqthread + 314
        23  libsystem_pthread.dylib         0x00007fff8eadafb9 start_wqthread + 13

    Or you may find the full crash report at

    4 Solutions Collect From Internet About “How to fix “Xcode quit unexpectedly while using the libclang.dylib plug-in.”?”

    There was a .m file in an #import statement!

    It was caused by one single line of code! Can’t belive it. Stole 4 hours of figuring out. Oh, it was combined by a @class statement.

    It shows up as an error, but xCode / Clang is crashing faster than you can even build. 😀

    The deadly pattern:


    #import "Two.m" // Not easy to spot actually.
    @interface One : NSObject


    @class One;
    @interface Two : NSObject
    @property (nonatomic, weak) One *one;

    I can’t reproduce it unless with the project I mentioned with over 200 classes. That must be some kind of race-condition.

    If you have an @Implementation in any Objective-C header file it seems to be enough to cause it to fail as well.

    In my case, I had an import to an umbrella header file inside of the umbrella header file itself.

    For example:

    Inside of MyFramework.h, I had:

    #import <MyFramework/MyFramework.h>

    The indexer hates this!

    From logs: IDEIndex PCH Creation Lock > looks like Xcode tries to index a project when crashing.

    So try to figure what can cause this in your project or source code, maybe compare your latest working version with current one.