On 7 Nov 2013, at 16:18, Andrew Madsen <[email protected]> wrote:
> Thanks for the reply Mike. I'm one of Patrick's colleagues. > > On Nov 6, 2013, at 5:28 AM, Mike Abdullah <[email protected]> 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. Ah, that’s a shame. Come to think of it, there’s a limit on how many security-scoped bookmarks you’re allowed to access at once. I wonder, does the problem seem to happen around a particular, fairly predictable, number of bookmarks? _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
