Re: iPhone: NSFileManager/NSDirectoryEnumerator Crash?
Re: iPhone: NSFileManager/NSDirectoryEnumerator Crash?
- Subject: Re: iPhone: NSFileManager/NSDirectoryEnumerator Crash?
- From: Jeffrey Walton <email@hidden>
- Date: Fri, 11 Mar 2011 06:24:34 -0500
On Fri, Mar 11, 2011 at 2:36 AM, Quincey Morris
<email@hidden> wrote:
> On Mar 9, 2011, at 16:33, Jeffrey Walton wrote:
>
> The
> code executes properly on the first invocation, but crashes on the
> second invocation. The cause of the crash is walker = [fileManager
> enumeratorAtPath:directory].
>
> You should post the error message and the backtrace at the time of the
> crash. "Crash" means different things in different contexts.
OK. In the future, is 'bt full' preferred?
> Any ideas on the cause? I experience the crash with both methods of
> retrieving the file manager. Are there known issues with
> enumeratorAtPath?
>
> No. Your symptoms, as far as they can be analyzed in the absence of specific
> information, sound like a memory management problem. The point at which the
> crash occurs is where the error was detected, not (necessarily) where the
> error really occurred.
>
> directory = [NSHomeDirectory()
> stringByAppendingPathComponent:@"Documents"];
> walker = [fileManager enumeratorAtPath:directory];
> while((file = [walker nextObject]) != nil)
>
> That's three objects you don't take ownership of after they're handed to
> you. I'd suggest starting by retaining them and releasing them before
> exiting from this piece of code. You can't assume they're autoreleased when
> handed to you (unless the documentation says so), and even then it's living
> dangerously to avoid retaining them when something allocation-heavy like
> directory enumeration is in progress.
> [This is not a garbage collected app, is it? If so, then the answer is
> different.]
OK. Thanks.
> According to 'NSFileManager Class Reference'
> (http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html):
>
> In iOS and Mac OS X v 10.5 and later you should consider
> using [[NSFileManager alloc] init] rather than the singleton
> method defaultManager. Instances of NSFileManager are
> considered thread-safe when created using
> [[NSFileManager alloc] init].
>
> Some time back, an expert from Apple said that this documentation isn't
> exactly correct. IIRC, there is [no longer, at least] anything special about
> [NSFileManager defaultManager] -- except, I suppose, that it's a singleton,
> so should only be used by a single thread at one time. '[[NSFileManager
> alloc] init]' produces unique instances that should also be used by a single
> thread at one time. IOW, more or less, each thread should use its own
> NSFileManager instance. That's the only restriction.
> Also, IIRC, none of the individual instances is thread safe in the sense
> that it can be used by multiple threads at the same time. [The thread
> safety, I assume, comes from the ability to have multiple instances working
> at the same time, accessing a shared file system, which something quite
> different.]
> But I'm saying all this from imperfect memory, so I might have it wrong.
OK - thanks. Do you have any recommendations on Mac OS X internals? In
the Windows world, I have Richter's 'Advanced Windows' series, and
Russinovich (et al) 'Windows Internals'. Great references that have
saved me more than once.
Jeff
_______________________________________________
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