Re: crash in
Re: crash in
- Subject: Re: crash in
- From: Michael Crawford <email@hidden>
- Date: Fri, 24 May 2013 11:49:23 -0700
TextWrangler (http://www.barebones.com/) will tell you whether the document
contains characters that aren't permitted by the encoding when you do a
Save As.
Note that DTD validators are incapable of validating the "payload" of XML
elements (the free tags between the opening and closing tag) as well as the
value of most attributes. While the choice of permissible attribute values
can be specified in a DTD, they aren't always. If that's the case, the
attribute values can be anything.
Try loading your source up with assertions. My own experience is that I
get the best bang for the buck by asserting that all my method input
parameters are within their expected ranges. While typically less useful,
it can also help to asert that return values are as expected.
You can also use assertions to validate class invariants. For example if
you have a Square object, you would assert that the four sides are all the
same length.
Of course your crash only occurs with this one document. Quite likely
illegal data in your doc is leading your code to overwrite memory.
Try Guard Malloc as well, and Valgrind (http://www.valgrind.org/). It runs
on Mac OS X now, but not iOS. Guard Malloc won't work right out of the box
for some reason I don't recall, but either here or in the Xcode list,
someone reported a way to fix the problem that prevents it from working.
Hope This Helps,
Mike
email@hidden
On Fri, May 24, 2013 at 11:15 AM, Chris Ridd <email@hidden> wrote:
>
> On 24 May 2013, at 18:31, Martin Hewitson <email@hidden>
> wrote:
>
> > Great. I found an on-line validator (
> http://www.w3schools.com/dom/dom_validate.asp) and it finds no errors.
> >
> > Back to the crash log: do the reported errors mean that there's
> something wrong with the XML file? I mean, this file is created by Core
> Data, by calling -saveToURL:... in the NSPersistentDocument subclass. So
> it's not really anything my app is doing. So unless the user somehow messed
> up the file, I suppose the file is in good order.
> >
> > So what else could be wrong?
> >
> > I was wondering about file encoding. The crash log ends with
> >
> > Thread 0 Crashed: Dispatch queue: com.apple.main-thread
> > 0 libSystem.B.dylib 0x00007fff8142c126 strtoull_l + 75
> > 1 com.apple.CoreData 0x00007fff898b7878 +[_PFRoutines
> convertCString:toUnsignedInt64:withBase:] + 40
> > 2 com.apple.CoreData 0x00007fff898cf3b0
> -[NSXMLDocumentMap _processInstanceNode:] + 240
>
> The file may be quite valid, but the parser is trying to decode an
> unsigned 64-bit integer into an actual variable. So maybe there's some
> issue with a really big (or somehow mangled) integer?
>
> Try setting a breakpoint on strtoull_l and see what kind of arguments it
> is getting.
>
> Chris
> _______________________________________________
>
> 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
>
--
Michael David Crawford
mdcrawford at gmail dot com
Custom Software Development for the iPhone and Mac OS X
http://www.dulcineatech.com/custom-software-development/
_______________________________________________
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