Re: URLByResolvingBookmarkData: crashes on 10.8
Re: URLByResolvingBookmarkData: crashes on 10.8
- Subject: Re: URLByResolvingBookmarkData: crashes on 10.8
- From: Andrew Madsen <email@hidden>
- Date: Thu, 07 Nov 2013 09:18:16 -0700
Thanks for the reply Mike. I'm one of Patrick's colleagues.
On Nov 6, 2013, at 5:28 AM, Mike Abdullah <email@hidden> wrote:
> 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?
In the course of our attempts to find a solution to this problem, we centralized all our calls to this method using a function. At this point, the body of the function consists solely of the code Patrick posted (at one point we were doing bookmark resolution on a single serial queue). The isStale and error parameters are passed by reference into the function:
NSURL *MIKDataResolveBookmarkData(NSData *bookmarkData, BOOL *isStale, NSError **resolveError)
{
return [NSURL URLByResolvingBookmarkData:bookmarkData
options:NSURLBookmarkResolutionWithSecurityScope
relativeToURL:nil
bookmarkDataIsStale:isStale
error:resolveError];
}
We saw this crash before we moved all calls to this method into a single function.
The same crash is easily repeatable in a simple test app using the equivalent CFURL function:
CFURLRef fileURL = CFURLCreateByResolvingBookmarkData(kCFAllocatorDefault, (CFDataRef)bookmark, options, NULL, NULL, &isStale, &error);
Not surprising as the NSURL method is presumably a simple call through to this function.
> 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.
>
> 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?
We saw your blog post about this. We’re always explicitly initializing our NSError parameter to nil (as we always do), but this is ARC code, so it should be set to nil anyway. For whatever it’s worth, I also had no problem reproducing this crash in a test app with ARC turned off.
-Andrew Madsen
_______________________________________________
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