On 5 Nov 2013, at 20:01, patrick machielse <patr...@hieper.nl> 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 (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
