Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
- Subject: Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
- From: Charles Srstka <email@hidden>
- Date: Sat, 22 Oct 2016 15:01:01 -0500
> On Oct 22, 2016, at 2:42 PM, Jean Suisse <email@hidden> wrote:
>
>>
>> On 22 Oct 2016, at 21:24, Quincey Morris <email@hidden <mailto:email@hidden>> wrote:
>>
>> On Oct 22, 2016, at 11:42 , Jean Suisse <email@hidden <mailto:email@hidden> <mailto:email@hidden <mailto:email@hidden>>> wrote:
>>>
>>> My app should get an access denied error (the enumerator should be nil for instance). It shouldn’t crash.
>>
>> It can’t return nil, because that is used to signal the end of the enumeration. I agree it’s nasty if it crashes, though.
>
> I am not talking about enumerator?.nextObject() but about manager.enumerator(at: includingPropertiesForKeys: options:), which in the API return an optional FileManager.DirectoryEnumerator?, which I expect to be nil when there is nothing to enumerate.
>
> However, the doc states:
>
> Returns: An NSDirectoryEnumerator object that enumerates the contents of the directory at url. If url is a filename, the method returns an enumerator object that enumerates no files—the first call to nextObject()returns nil.
>
> So, why make it an optional value at all?
>
>>
>>> Though it looks like I am trying to access "/.DocumentRevisions-V100/“, it is not what I am trying to achieve.
>>>
>>> At some point my app needs to enumerate user-selected directories. The issue is I get a crash when directories such as "/.DocumentRevisions-V100/“ are present.
>>> I cannon reasonably maintain a list of “don’t enumerate” directories.
>>
>> It’s still not quite clear what your real code is trying to do. If you were enumerating the *root* directory *shallowly* (.skipsSubdirectoryDescendants), and you hit this directory, you should *not* try to descend explicitly into this directory (or any directory whose name begins with a period, I suppose) as your sample code does. If you were doing a deep enumeration from the root directory, you wouldn’t be executing shallow enumeration code as in your sample code.
>
> Yes, I enumerate shallowly. Yes I hit the directory. And yes, the user may take an action that will lead my app to try enumerating directories such as "/.DocumentRevisions-V100/“ shallowly.
> The finder doesn’t crash when I try to open .DocumentRevisions-V100. Neither should my app.
>
>> Can you use the .skipsHiddenFiles option for your real enumerator? That will skip files and directories whose name starts with a period.
>
> I could. But I still may hit directories that the user does not have the permission to access. .DocumentRevisions-V100 is really just for the example.
>
>>
>>> To refine, what difference is there between ObjC’s
>>> for (NSURL* file in enumerator)
>>>
>>> and swift’s
>>>
>>> while let file = enumerator?.nextObject() as? URL
>>> ?
>>
>> You’re comparing unlike things. Regardless of language, “for … in” and “while … nextObject” use different mechanisms for maintaining state between iterations. What does the Swift version of the “for … in” loop do?
>
> Jens asked if an equivalent in ObjC would crash. That’s what I came up with. The for … in loop performs gathers data about the file and folders, puts them in an array, returns it to the caller function, then the app continues interacting with the user.
I just tried it myself, and indeed got your crash. The backtrace is:
* thread #1: tid = 0x3f24f, 0x00000001000ca265 foo`static Foundation.DateComponents._unconditionallyBridgeFromObjectiveC (Swift.Optional<__ObjC.NSDateComponents>) -> Foundation.DateComponents with unmangled suffix "_merged" + 85, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00000001000ca265 foo`static Foundation.DateComponents._unconditionallyBridgeFromObjectiveC (Swift.Optional<__ObjC.NSDateComponents>) -> Foundation.DateComponents with unmangled suffix "_merged" + 85
frame #1: 0x000000010000204b foo`thunk + 59 at main.swift:0
frame #2: 0x00007fff78be6c82 Foundation`-[NSURLDirectoryEnumerator nextObject] + 101
* frame #3: 0x0000000100001888 foo`main + 952 at main.swift:17
frame #4: 0x00007fff8c1d5255 libdyld.dylib`start + 1
It looks like we’ve got a bridging issue here; my guess is that Objective-C is presenting nil to something that Swift didn’t expect to be optional. It’s pretty obviously a bug; I’d file a Radar on it.
Charles
_______________________________________________
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