Re: How to debug crash in NSOperation?
Re: How to debug crash in NSOperation?
- Subject: Re: How to debug crash in NSOperation?
- From: "Gerriet M. Denkmann" <email@hidden>
- Date: Tue, 28 Mar 2017 13:46:19 +0700
Sent from my iPhone
> On 28 Mar 2017, at 11:41, Quincey Morris <email@hidden> wrote:
>
>> 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.
>
I use the result to print an error message. But you are right: I should abandon the whole operation in case of error.
> 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.
As the array in question contains strings, none of which should contain a \n I was thinking of converting it into a string, which would then written as UTF16 (which would have the further advantage of reducing the size to about 40%).
>
> 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.
There probably will exist an old, not up to date version already.
>
> 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.
I will abandon the atomic write and just rely on the outcome of the write.
If it fails I have no interest in this file at all - the old version is useless anyway.
>
> 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.
This is my real problem: so far I have seen this error twice - within 250 days. Using the app several times per day.
If I could reproduce the error I am confident of fixing it.
I was suspecting a relation with sleep - the first time it occurred at 3:00 (computer should be sleeping) the second time at 17:00 (unlikely to be sleeping, but I'm not sure)
Thanks for your suggestions!
Kind regards
Gerriet
_______________________________________________
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