Re: Sudden and hard to reproduce crashes in libcache
Re: Sudden and hard to reproduce crashes in libcache
- Subject: Re: Sudden and hard to reproduce crashes in libcache
- From: Dragan Milić <email@hidden>
- Date: Tue, 13 Mar 2012 09:56:16 +0000
Just an update on this issue:
On uto 21.02.2012., at 14.48, Dragan Milić wrote:
> I'm using higher level 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.
Apparently, it's a bug in NSCache. On http://files.me.com/milke/t5ufx5 can you find a super simple sample app to reproduce it every time without any problem. It looks like -[NSString stringWithFormat:] (and possibly other calls) can return the same pointer rather than creating new object every call. Perhaps it's trying to reuse strings to save memory? NSCache seems not to like that and crashes. If I wrap the strings in a simple holder object, which has nothing more than a string as it's content ivar, that solves the crashing problem. But it's still completely incorrect behaviour on NSCache part.
I think this makes NSCache (at the moment) almost unusable in real world applications, because you never now whether and when it's going to crash. Maybe never, maybe immediately. I encourage everyone (especially those using NSCache) to file a bug report to Apple. If they get a lot of duplicates on the same issue, they may hopefully do something quicker. NSCache was introduced for object caching and memory saving and having to wrap every cached object in a holder object defies cache's purpose (kind of).
-- Dragan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden