当autoreleasepool耗尽时，SIGSEGV SEGV_ACCERR在NSFileAttributes dealloc中崩溃？

Question

使用NSFileManager在后台线程中获取文件大小时，我遇到了一个奇怪的崩溃。

我有一个名为localFileSize的歌曲对象的属性：

- (unsigned long long)localFileSize
{
    return [[[NSFileManager defaultManager] attributesOfItemAtPath:self.currentPath error:NULL] fileSize];
}

在我的类中处理我的音频播放（使用第三方音频库，而不是AQS或Core Audio），有一个文件长度回调函数在音频库的播放线程中调用，所以不是主线。

在该文件长度函数中，我在@autoreleasepool中读取我的歌曲对象的localFileSize属性。在函数结束时，当池耗尽时，有时会出现NSFileAttributes对象的dealloc方法崩溃。我自己无法重现它，但我有14个崩溃日志来解决这个问题。

以下是其中一个崩溃日志的相关部分：

Thread 8 Crashed:
0   libobjc.A.dylib                     0x3262c4e8 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE4growEj + 67
1   libobjc.A.dylib                     0x32638d81 _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16InsertIntoBucketERKS2_RKmPSt4pairIS2_mE + 56
2   libobjc.A.dylib                     0x3262b09d _ZN4objc8DenseMapIP11objc_objectmLb1ENS_12DenseMapInfoIS2_EENS3_ImEEE16FindAndConstructERKS2_ + 44
3   libobjc.A.dylib                     0x3262b139 _objc_rootReleaseWasZero + 92
4   libobjc.A.dylib                     0x3262b0ad _objc_rootRelease + 12
5   Foundation                          0x31fbab81 -[NSFileAttributes dealloc] + 60
6   libobjc.A.dylib                     0x3262b0c5 _objc_rootRelease + 36
7   libobjc.A.dylib                     0x3262cdb7 objc_release + 38
8   libobjc.A.dylib                     0x3262be0d _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 224
9   libobjc.A.dylib                     0x3262bd29 _objc_autoreleasePoolPop + 12
10  CoreFoundation                      0x35b0ce8f _CFAutoreleasePoolPop + 18
11  Foundation                          0x31f8aaf1 -[NSAutoreleasePool drain] + 128
12  iSub                                0x000fb6cb MyFileLenProc (AudioEngine.m:320)
13  iSub                                0x001623d8 BASS_FX_TempoCreate + 5160
14  iSub                                0x0016261c BASS_FX_TempoCreate + 5740
15  iSub                                0x0017f42c BASS_ChannelIsActive + 27424
16  AudioToolbox                        0x364905d9 _ZN19AudioConverterChain19DirectCallInputProcEPmS0_P15AudioBufferListPPK28AudioStreamPacketDescription + 228
17  AudioToolbox                        0x36465ee3 _ZN14CodecConverter13CallInputProcERm + 266
18  AudioToolbox                        0x3646588d _ZN14CodecConverter17DecoderFillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 576
19  AudioToolbox                        0x36465649 _ZN14CodecConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 28
20  AudioToolbox                        0x36452c99 _ZN19AudioConverterChain12RenderOutputEP12CABufferListmRmP28AudioStreamPacketDescription + 92
21  AudioToolbox                        0x36452b53 _ZN22BufferedAudioConverter10FillBufferERmR15AudioBufferListP28AudioStreamPacketDescription + 186
22  AudioToolbox                        0x36452929 AudioConverterFillComplexBuffer + 356
23  iSub                                0x0017d9f8 BASS_ChannelIsActive + 20716
24  iSub                                0x00184f70 BASS_ChannelSetPosition + 640
25  iSub                                0x00186eb4 BASS_ChannelGetData + 1032
26  iSub                                0x000fc787 __35-[AudioEngine keepRingBufferFilled]_block_invoke_0 (AudioEngine.m:752)
27  libdispatch.dylib                   0x35e3fd55 _dispatch_call_block_and_release + 12
28  libdispatch.dylib                   0x35e4b7a3 _dispatch_worker_thread2 + 262
29  libsystem_c.dylib                   0x30fbb1cf _pthread_wqthread + 294

任何可能导致这种情况的想法？

此外，如果它有任何不同，在报告这些崩溃时，该项目没有使用ARC。我最近转换为ARC，但还没有发布更新。尽管如此，我不会在这种情况下产生任何不同。

此外，值得注意的是，即使我的应用支持4.2及更高版本，所有崩溃报告都来自iOS 5.0.1和5.1。那么可能是iOS 5的某种bug？

Answer 1

我想知道什么时候改变了？我清楚地记得[NSFileManager defaultManager]不是线程安全的。而顺便说一下，我们也有同样的问题从多个线程调用defaultManager。看起来其他人也会以同样的方式记住它：http://useyourloaf.com/blog/2011/06/12/nsfilemanager-defaultmanager-is-not-thread-safe.html

Answer 2

不要使用后台线程中的+defaultManager。只需分配+ init一个实例，使用它，并且（如果不使用ARC）释放它。这是错误的。

Answer 3

使用类似的东西结束文件大小：

#include <sys/stat.h>

struct stat fileInfo;
off_t fileSize; // Can cast to long long

stat(filename, &fileInfo);
fileSize = fileInfo.st_size;

或者你可以尝试创建新的NSFileManager对象，因为看起来文档可能不完全真实的线程安全。