當autoreleasepool耗盡時，NSFileAttributes dealloc中出現SIGSEGV SEGV_ACCERR崩潰？

當使用NSFileManager在後臺線程中獲取文件大小時，我收到了一個奇怪的崩潰。當autoreleasepool耗盡時，NSFileAttributes dealloc中出現SIGSEGV SEGV_ACCERR崩潰？

我有一個名爲localFileSize一首歌對象的屬性：

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

在我的類來處理我的音頻播放（使用第三方音頻庫，不AQS或核心音頻），有一個文件長度在音頻庫的回放線程中調用的回調函數，所以不是主線程。

在該文件長度函數中，我正在讀取@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，但還沒有發佈更新。無論如何，我不會在這種情況下產生任何影響。

另外，值得注意的是，所有的崩潰報告都來自iOS 5.0.1和5.1，儘管我的應用程序支持4.2及以上版本。所以潛在的iOS 5的某種錯誤？

來源

2012-04-23 Ben Baron

結束了使用這樣的事情來獲得文件大小：

#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-23 20:46:05

~~請勿在後臺線程中使用 +defaultManager。只要alloc + init一個實例，使用它，並且（如果不使用ARC）釋放它。~~ 這是錯的。

來源

2012-04-23 23:29:53

真的嗎？ https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/nsfilemanager_Class/Reference/Reference.html說：「可以從多個線程安全地調用共享的'NSFileManager'對象的方法「。 – 2012-04-23 23:32:25

嗯，你說得對。我撤回了我的答案。 – 2012-04-23 23:51:12

我想知道這是什麼時候發生的變化？我清楚地記得[NSFileManager defaultManager]不是線程安全的。順便說一下，我們也有從多個線程調用defaultManager的相同問題。它看起來像其他人都記得用同樣的方式：http://useyourloaf.com/blog/2011/06/12/nsfilemanager-defaultmanager-is-not-thread-safe.html

來源

2012-08-23 20:12:40

嗯，不知道。但無論如何，我轉而使用C函數來獲取文件信息，並從那時起就沒有任何問題。 – 2012-08-23 20:38:36

當autoreleasepool耗盡時，NSFileAttributes dealloc中出現SIGSEGV SEGV_ACCERR崩潰？

回答

相關問題