0

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

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

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

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

在该文件长度函数中，我正在读取我的歌曲对象的 localFileSize 属性，位于 @autoreleasepool 中。在函数结束时，当池被耗尽时，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，但尚未发布更新。无论如何，我认为在这种情况下不会有任何区别。

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

4

3 回答 3

1

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

于 2012-08-23T20:12:40.567 回答
0

最终使用这样的东西来获取文件大小：

#include <sys/stat.h>

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

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

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

于 2012-08-23T20:46:05.993 回答
0

不要使用+defaultManager来自后台线程。只需 alloc+init 一个实例，使用它，然后（如果不使用 ARC）释放它。那是错误的。

于 2012-04-23T23:29:53.760 回答