On Feb 21, 2012, at 6:50 AM, Dragan Milić <mi...@mac.com> wrote:

> First of all, I apologise if this is not the right topic for this list.
> 
> Some beta testers of an application I'm working on experience rather strange 
> and sudden crashes, very often when the application is doing nothing, just 
> sitting idle in the background. The crash happens in a thread named 
> "com.apple.root.default-priority" and it's not even controlled by the 
> application. As far as I figure it out, it is triggered by the system to 
> release some memory from caches the application uses. This is the part of the 
> crash report related to that particular thread:
> 
> Thread 8 Crashed:: Dispatch queue: com.apple.root.default-priority
> 0   libsystem_kernel.dylib            0x00007fff8d847ce2 __pthread_kill + 10
> 1   libsystem_c.dylib                 0x00007fff9009e7d2 pthread_kill + 95
> 2   libsystem_c.dylib                 0x00007fff9008fa7a abort + 143
> 3   libc++abi.dylib                   0x00007fff8a1e77bc abort_message + 214
> 4   libc++abi.dylib                   0x00007fff8a1e4fcf default_terminate() 
> + 28
> 5   libobjc.A.dylib                   0x00007fff8a69a1b9 _objc_terminate + 94
> 6   libc++abi.dylib                   0x00007fff8a1e5001 
> safe_handler_caller(void (*)()) + 11
> 7   libc++abi.dylib                   0x00007fff8a1e505c std::terminate() + 16
> 8   libc++abi.dylib                   0x00007fff8a1e6152 __cxa_throw + 114
> 9   libobjc.A.dylib                   0x00007fff8a699e7a objc_exception_throw 
> + 327
> 10  com.apple.CoreFoundation          0x00007fff8c8b92a9 -[NSException raise] 
> + 9
> 11  com.apple.ExceptionHandling       0x0000000100332e0a 
> NSExceptionHandlerUncaughtSignalHandler + 37
> 12  libsystem_c.dylib                 0x00007fff900f0cfa _sigtramp + 26
> 13  com.apple.CoreFoundation          0x00007fff8c793c0b CFRelease + 27
> 14  libcache.dylib                    0x00007fff8fb4d8e4 _value_entry_remove 
> + 142
> 15  libcache.dylib                    0x00007fff8fb4d9cd _entry_unmap + 81
> 16  libcache.dylib                    0x00007fff8fb4da71 _entry_evict + 153
> 17  libcache.dylib                    0x00007fff8fb4db04 _evict_last + 106
> 18  libcache.dylib                    0x00007fff8fb4dcf2 
> _cache_enforce_limits + 34
> 19  libcache.dylib                    0x00007fff8fb4dea5 
> cache_handle_memory_pressure + 125
> 20  libdispatch.dylib                 0x00007fff888bf2b6 
> _dispatch_source_invoke + 635
> 21  libdispatch.dylib                 0x00007fff888bbf77 
> _dispatch_queue_invoke + 71
> 22  libdispatch.dylib                 0x00007fff888bb760 
> _dispatch_worker_thread2 + 198
> 23  libsystem_c.dylib                 0x00007fff9009e3da _pthread_wqthread + 
> 316
> 24  libsystem_c.dylib                 0x00007fff9009fb85 start_wqthread + 13
> 
> All those crash reports for the crashing thread look the same. Only a few 
> people experience them, but regularly. For others, it practically impossible 
> to reproduce.
> 
> I'm using higher level Cocoa NSCache API to cache objects. Cached objects are 
> various image representations and much rarely attributed strings and NSNumber 
> instances. I see the crash happens after CFRelease() call, but I can't figure 
> out why. If I try to do CFRelease(NULL), I get almost the same sequence, 
> similar to:
> 
> 3   libc++abi.dylib                   0x00007fff8a1e77bc abort_message + 214
> 4   libc++abi.dylib                   0x00007fff8a1e4fcf default_terminate() 
> + 28
> 5   libobjc.A.dylib                   0x00007fff8a69a1b9 _objc_terminate + 94
> 6   libc++abi.dylib                   0x00007fff8a1e5001 
> safe_handler_caller(void (*)()) + 11
> 7   libc++abi.dylib                   0x00007fff8a1e505c std::terminate() + 16
> 8   libc++abi.dylib                   0x00007fff8a1e6152 __cxa_throw + 114
> 9   libobjc.A.dylib                   0x00007fff8a699e7a objc_exception_throw 
> + 327
> 10  com.apple.CoreFoundation          0x00007fff8c8b92a9 -[NSException raise] 
> + 9
> 11  com.apple.ExceptionHandling       0x0000000100332e0a 
> NSExceptionHandlerUncaughtSignalHandler + 37
> 12  libsystem_c.dylib                 0x00007fff900f0cfa _sigtramp + 26
> 
> But I don't know who and why does (if at all) that NULL pointer release. The 
> documentation for libcache says "Calling cache functions from cache callbacks 
> should be avoided to prevent deadlock." I thought maybe when releasing cached 
> objects libcache calls callback methods to release memory and then image 
> representations are doing some caching on their own, which would effectively 
> be calling cache functions from cache callbacks. But this is just a wild 
> guess, I've no idea what is really going on.
> 
> So, I'd really appreciate if anyone can help me with this. I've got no idea 
> whether it's a but in the application, or the OS. If necessary, I can send 
> the full crash report and also explain what object are being cached using 
> NSCache.

Yep, that's CFRelease(NULL), plus ExceptionHandling.framework catching the Unix 
signal and trying to turn it into an Objective-C exception.

That background thread is part of NSCache. This could be a bug in your use of 
NSCache, a memory smasher somewhere, or a bug in NSCache itself. 

You may be able to reproduce this by forcing the app into a low memory 
situation. That background thread is evicting NSCache contents in responds to 
low memory. Once you can reproduce, you should try zombies and guard malloc.


-- 
Greg Parker     gpar...@apple.com     Runtime Wrangler



_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to