SIGSEGV SEGV_ACCERR crash in NSFileAttributes dealloc when autoreleasepool is drained? - iphone

Question

I'm getting a strange crash when using NSFileManager to get the file size in a background thread.
I have a property of a song object called localFileSize:
- (unsigned long long)localFileSize
{
return [[[NSFileManager defaultManager] attributesOfItemAtPath:self.currentPath error:NULL] fileSize];
}
In my class that handles my audio playback (using a 3rd party audio library, not AQS or Core Audio), there is a file length callback function that is called in the audio library's playback thread, so not the main thread.
In that file length function, I'm reading the localFileSize property of my song object, inside an #autoreleasepool. At the end of the function, when the pool is drained, there appears to sometimes be a crash with the NSFileAttributes object's dealloc method. I can't reproduce it myself, but I have 14 crash logs with this issue.
Here is the relevant portion of one of the crash logs:
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
Any ideas what could be causing this?
Also, if it makes any difference, at the time these crashes were reported the project was not using ARC. I recently converted to ARC, but have not released the update yet. I don't that would make any difference in this case though anyway.
Also, it's worth noting that all of the crash reports have been from iOS 5.0.1 and 5.1, even though my app supports 4.2 and above. So potentially an iOS 5 bug of some kind?

Answer 1

I wonder when did that change? I clearly remember [NSFileManager defaultManager] not being thread-safe. And, by the way, we are having the same issue calling defaultManager from multiple threads as well. It looks like other people remember it the same way: http://useyourloaf.com/blog/2011/06/12/nsfilemanager-defaultmanager-is-not-thread-safe.html

Answer 2

Don't use the +defaultManager from background threads. Just alloc+init an instance, use it, and (if not using ARC) release it. That was just wrong.

Answer 3

Ended up using something like this to get file size:
#include <sys/stat.h>
struct stat fileInfo;
off_t fileSize; // Can cast to long long
stat(filename, &fileInfo);
fileSize = fileInfo.st_size;
Or you can try creating new NSFileManager objects, as it appears the docs may not be completely truthful about thread safety.