Thanks for the reply Mike. I'm one of Patrick's colleagues.
On Nov 6, 2013, at 5:28 AM, Mike Abdullah <mabdul...@karelia.com> 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 (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
