如何修复“Xcode 在使用 libclang.dylib 插件时意外退出”？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/23065373/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to fix "Xcode quit unexpectedly while using the libclang.dylib plug-in."?
提问by Geri Borbás
I have this every time in a short while after I start xCode (5.1.1).
在我启动 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 reinstalledxCode, without any effect, still says the same.
删除了用户数据，关闭了源代码控制（如某些帖子所建议的那样），没有效果，仍然崩溃（同时显示索引......永远不会完成）。即使重新安装了xCode，没有任何效果，仍然如此。
Did anybody fixed such an xCode?
有人修复了这样的 xCode 吗？
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 com.apple.dt.IDEFoundation 0x0000000106ac63af -[IDEIndexClangTranslationUnit cxTranslationUnit] + 331
7 com.apple.dt.IDEFoundation 0x0000000106c2c11a +[IDEIndexClangDataSource translationUnitForPCHFile:arguments:session:create:] + 259
8 com.apple.dt.IDEFoundation 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 com.apple.dt.DVTFoundation 0x0000000105fce5cf -[DVTDispatchLock performLockedBlock:] + 95
12 com.apple.dt.IDEFoundation 0x0000000106cf4932 -[IDEIndex createPCHFile:arguments:hashCriteria:target:session:willIndex:translationUnit:] + 919
13 com.apple.dt.IDEFoundation 0x0000000106ac4985 -[IDEIndexClangDataSource generateDataForJob:] + 1274
14 com.apple.dt.IDEFoundation 0x0000000106ac42fb -[IDEIndexDataSource processJob:] + 147
15 com.apple.dt.IDEFoundation 0x0000000106ac3e33 +[IDEIndexingEngine runFileJob:] + 732
16 com.apple.dt.IDEFoundation 0x0000000106ac3550 -[IDEIndexingJob run] + 161
17 com.apple.dt.IDEFoundation 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 https://gist.github.com/eppz/10669132
或者您可以在https://gist.github.com/eppz/10669132 上找到完整的崩溃报告
回答by Geri Borbás
There was a .mfile in an #importstatement!
声明中有.m文件#import！
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 @classstatement.
它是由一行代码引起的！无法相信。偷了 4 个小时的时间。哦，它是由一个@class语句组合而成的。
It shows up as an error, but xCode / Clang is crashing faster than you can even build. :D
它显示为错误，但 xCode / Clang 崩溃的速度甚至比您构建的还要快。:D
The deadly pattern:
致命模式：
One.h
一小时
#import "Two.m" // Not easy to spot actually.
@interface One : NSObject
@end
Two.h
两小时
@class One;
@interface Two : NSObject
@property (nonatomic, weak) One *one;
@end
I can't reproduce it unless with the project I mentioned with over 200 classes. That must be some kind of race-condition.
除非使用我提到的 200 多个类的项目，否则我无法重现它。那一定是某种竞争条件。
回答by Ryan Poolos
If you have an @Implementation in any Objective-C header file it seems to be enough to cause it to fail as well.
如果您在任何 Objective-C 头文件中有一个 @Implementation，它似乎也足以导致它失败。
回答by Gene Z. Ragan
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:
在 MyFramework.h 中，我有：
#import <MyFramework/MyFramework.h>
The indexer hates this!
索引器讨厌这个！
回答by Vincent Guerci
From logs: IDEIndex PCH Creation Lock> looks like Xcode tries to index a project when crashing.
从日志：IDEIndex PCH Creation Lock> 看起来 Xcode 在崩溃时尝试索引项目。
So try to figure what can cause this in your project or source code, maybe compare your latest working version with current one.
因此，请尝试找出在您的项目或源代码中可能导致这种情况的原因，也许将您的最新工作版本与当前版本进行比较。
