Re: URLByResolvingBookmarkData: crashes on 10.8
Re: URLByResolvingBookmarkData: crashes on 10.8
- Subject: Re: URLByResolvingBookmarkData: crashes on 10.8
- From: Mike Abdullah <email@hidden>
- Date: Wed, 06 Nov 2013 12:28:14 +0000
On 5 Nov 2013, at 20:01, patrick machielse <email@hidden> wrote:
> We're developing an application that needs to track a lot of files (say 10k).
>
> As recommended, we use url / bookmarks to store references to file system objects.
>
>
> We regularly see crashes that originate here:
>
> return [NSURL URLByResolvingBookmarkData:bookmarkData
> options:NSURLBookmarkResolutionWithSecurityScope
> relativeToURL:nil
> bookmarkDataIsStale:isStale
> error:resolveError];
This line of code jumps out at me as slightly suspicious for the isStale and resolveError parameters. They are supposed to be passed by reference. Is this the real code you’re showing us? If so, are those variables already passed in by reference from somewhere else? Or is this an approximation of your code?
One bookmark bug I’ve run into before is that if you pass a pointer to garbage into the error parameter, it will sometimes crash. For example:
NSError *error;
NSURL *url = [NSURL URLByResolvingBookmarkData:bookmarkData
options:NSURLBookmarkResolutionWithSecurityScope
relativeToURL:nil
bookmarkDataIsStale:NULL
error:&error];
Sometimes the bookmark internals will try to read from *error and then crash because that’s not nil or a real error object. The above code is fine by Cocoa error handling rules, but NSURL disobeys that. The only workaround I’ve found is to do:
NSError *error = nil;
at the start and then all is fine.
Of course, this should only be a problem for non-ARC code. ARC should be setting error to nil in the first bit of code, anyway. I wonder, is it possible you’re getting a pointer to garbage getting passed into your code from elsewhere that’s non-ARC?
>
>
> The backtrace looks like this:
>
> 0 com.apple.CoreFoundation 0x00007fff93360711 __CFTypeCollectionRetain + 33
> 1 com.apple.CoreFoundation 0x00007fff9338dac2 __CFDictionaryRetainValue + 50
> 2 com.apple.CoreFoundation 0x00007fff9335fb8a __CFBasicHashAddValue + 1226
> 3 com.apple.CoreFoundation 0x00007fff93366268 CFBasicHashAddValue + 3176
> 4 com.apple.CoreFoundation 0x00007fff93399e5f CFDictionaryCreate + 143
> 5 com.apple.CoreFoundation 0x00007fff933a073c CFErrorCreateWithUserInfoKeysAndValues + 124
> 6 com.apple.CoreServicesInternal 0x00007fff8a07bff2 reportErrorForURL(__CFError**, long, __CFURL const*) + 94
> 7 com.apple.CoreServicesInternal 0x00007fff8a063037 _CFURLCreateByResolvingBookmarkData + 1857
> 8 com.apple.CoreFoundation 0x00007fff93418e5e +[NSURL URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error:] + 78
>
>
> And it prints:
>
> Application Specific Information:
> *** __CFTypeCollectionRetain() called with NULL; likely a collection has been corrupted ***
>
>
> Calling this routine again with exactly the same parameters succeeds —- there seems to be nothing wrong with the input we supply. We've tried synchronizing all access to this method, and only calling this method on the main thread. It didn't help.
>
> We have a test application that can trigger the crash on 10.8. We used a support incident to get Apple's help on this. It seems likely now that this is a bug in the frameworks that was supposedly fixed in 10.9 (we have not yet seen this happen on 10.9). But we must support 10.8 at the very least.
>
> Our app needs to support 10.7 / 10.8 / 10.9, is Sandboxed, and uses ARC.
>
>
> Unless we find a workaround for this bug we can't ship Sandboxed and / or on the App Store. And we will need to rewrite the file reference part of our app.
>
> Has anyone run into this issue before, and if so is there a way to avoid this problem?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden