• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jean Suisse <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Quincey Morris <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jean Suisse <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jens Alfke <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jean Suisse <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jean Suisse <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Quincey Morris <email@hidden>)
 >Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/ (From: Jean Suisse <email@hidden>)

  • Prev by Date: Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
  • Next by Date: Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
  • Previous by thread: Re: EXC_BAD_INSTRUCTION when enumerating /.DocumentRevisions-V100/
  • Next by thread: initWithRequest:delegate:startImmediately
  • Index(es):
    • Date
    • Thread