Re: How to debug crash in NSOperation?
Re: How to debug crash in NSOperation?
- Subject: Re: How to debug crash in NSOperation?
- From: Quincey Morris <email@hidden>
- Date: Mon, 27 Mar 2017 21:41:46 -0700
On Mar 26, 2017, at 22:04 , Gerriet M. Denkmann <email@hidden> wrote:
>
> [ arrayOfStrings writeToFile: “directoryPath/SortedKeys.plist” atomically: YES ]; ← pseudo code
A couple of points about this line of code, assuming that the method -[NSArray writeToFile:atomically:] is actually being used:
1. This method has a YES/NO result, which you really shouldn’t ignore, if you do.
2. This method is a file API with no outError parameter. All such methods should be regarded as ancient, undesirable to use, and superseded by a newer method that does have an outError parameter. The fact that there is no newer method with an outError parameter tells you that Apple has (essentially) abandoned this method, and that the replacement API requires a different approach. My guess is that the intended replacement is to convert the NSArray to a NSData object yourself (through serialization, archiving, or some similar technique), and then using one of the more modern NSData file writing methods to get it onto disk.
3. Really, don’t use path-based methods any more. Use the URL-based variant. (In this case, there is one, but it’s also lacking an outError parameter, so it also should be abandoned.)
However, none of the above can explain your crash. The symptoms of the crash indicate that the directory listed a file called “SortedKeys.plist”, but the file didn’t actually exist (or couldn’t be read), which is on the face of it pretty weird. That leads me to:
4. You might use “atomically: NO” instead of “atomically: YES”. It’s not clear whether you expect “SortedKeys.plist” to exist already in the directory, but I’m guessing not, or that you could delete it manually first. If the file doesn’t exist, and if you change your code to capture and handle file-write errors properly, then writing atomically doesn’t have any value, and it may in rare cases turn out to be actively harmful.
A successful non-atomic write is an open/write/close sequence. An atomic write does that to a temp location on the same HFS volume, then does a file system atomic “swap” operation to exchange the data of the real and temp files. On a non-local (e.g. network) or non-HFS volume, the file manager may not have access to an atomic file swap, so might have to simulate with renames, moves and/or copies.
So, an atomic file write involves a longer, possibly quite a lot longer, sequence of file system operations, and it’s not totally outside the bounds of possibility that there might be some reordering between this sequence and other sequences, perhaps even the subsequent directory scan that you do. It doesn’t seem outside the bounds of possibility that the directory scan might see the directory in a transitional state.
This is highly speculative, and other people may have reasons to argue that such a reordering cannot legally take place, but if you use a non-atomic write you eliminate any possible timing window on the directory scan, I think.
That doesn’t really touch the “how to debug?” question, to which I don’t know the answer, except to suggest you play around trying to make the problem more reproducible.
_______________________________________________
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