crash in

  • Dear list,

    I have a report from a user that they, all of a sudden, can't open an existing document using my app without causing a crash. The document is made for and by the app. And as far as I can glean from the description, it was working just fine until one day (recently) it started causing these crashes. I got the document off the user and it crashes for me too. The app uses an NSPersistentDocument subclass to store the project data. The crash seems to be something to do with the XML file, but the file is >6000 lines long, so it's hard to validate it by hand (yes, probably I should stop using XML format for these core data stores).

    Can anyone see something in the crash log that may help me to figure out what's happening?

    Many thanks,

    Martin

    Date/Time:      2013-05-24 16:22:07.418 +0100
    OS Version:      Mac OS X 10.6.8 (10K549)
    Report Version:  6

    Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
    Crashed Thread:  0  Dispatch queue: com.apple.main-thread

    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
    3  com.apple.CoreData               0x00007fff898d0c8a -[NSXMLDocumentMap _processDocument] + 282
    4  com.apple.CoreData               0x00007fff898d1037 -[NSXMLDocumentMap initWithDocument:forStore:] + 279
    5  com.apple.CoreData               0x00007fff898d33c0 -[NSXMLObjectStore initWithPersistentStoreCoordinator:configurationName:URL:options:] + 1248
    6  com.apple.CoreData               0x00007fff89847137 -[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:] + 711
    7  com.apple.AppKit                 0x00007fff88db5b90 -[NSPersistentDocument configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:] + 255
    8  com.bobsoft.TeXnicle             0x000000010000b5e1 0x100000000 + 46561
    9  com.apple.AppKit                 0x00007fff89033d1e -[NSPersistentDocument(NSDeprecatedInternal) _configurePersistentStoreCoordinatorForURL:ofType:error:] + 183
    10  com.apple.AppKit                 0x00007fff88db57bb -[NSPersistentDocument readFromURL:ofType:error:] + 124
    11  com.apple.AppKit                 0x00007fff88c8830e -[NSDocument initWithContentsOfURL:ofType:error:] + 265
    12  com.apple.AppKit                 0x00007fff88c93b88 -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] + 332
    13  com.apple.AppKit                 0x00007fff88c93978 -[NSDocumentController openDocumentWithContentsOfURL:display:error:] + 734
    14  com.bobsoft.TeXnicle             0x0000000100121028 0x100000000 + 1183784
    15  com.apple.AppKit                 0x00007fff88aaeeda -[NSApplication sendAction:to:from:] + 95
    16  com.apple.AppKit                 0x00007fff88aaee39 -[NSControl sendAction:to:] + 94
    17  com.apple.AppKit                 0x00007fff88b3a84b -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1715
    18  com.apple.AppKit                 0x00007fff88b6b37a -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 555
    19  com.apple.AppKit                 0x00007fff88b392f5 -[NSControl mouseDown:] + 624
    20  com.apple.AppKit                 0x00007fff88a533a7 -[NSWindow sendEvent:] + 5409
    21  com.apple.AppKit                 0x00007fff88988afa -[NSApplication sendEvent:] + 4719
    22  com.apple.AppKit                 0x00007fff8891f6de -[NSApplication run] + 474
    23  com.apple.AppKit                 0x00007fff889183b0 NSApplicationMain + 364
    24  com.bobsoft.TeXnicle             0x0000000100002082 0x100000000 + 8322
    25  com.bobsoft.TeXnicle             0x0000000100002054 0x100000000 + 8276
  • On May 24, 2013, at 9:11 AM, Martin Hewitson <martin.hewitson...> wrote:

    > The crash seems to be something to do with the XML file, but the file is >6000 lines long, so it's hard to validate it by hand

    There are automatic validators, including an online one run by the W3C. I can’t remember the URL but it should be pretty easy to find.

    —Jens
  • Try loading your document into a DOM with either Xerces-C - actually C++ -
    or Xerces - Java.  It's not hard at all to write a program just a few lines
    long to do that.

    If your document is not conformant to XML, Xerces will complain.

    If your format isn't that complex, it's not hard to write a DTD.  There are
    some open source packages that will do DTD validation now.  DTDs are
    written in SGML using metacharacters that aren't hard to learn.  I've never
    written an XML schema, but they're meant to be easier to write than DTDs,
    yet provide stricter specification compliance.  There are some open source
    schema validators.  The instructions for the DocBook 5 XML tell you how to
    validate it with a Java validator, but I don't recall its name.

    Best of luck,

    Mike
    <mdcrawford...>

    On Fri, May 24, 2013 at 9:11 AM, Martin Hewitson <martin.hewitson...>
    > wrote:

    > Dear list,
    >
    > I have a report from a user that they, all of a sudden, can't open an
    > existing document using my app without causing a crash. The document is
    > made for and by the app. And as far as I can glean from the description, it
    > was working just fine until one day (recently) it started causing these
    > crashes. I got the document off the user and it crashes for me too. The app
    > uses an NSPersistentDocument subclass to store the project data. The crash
    > seems to be something to do with the XML file, but the file is >6000 lines
    > long, so it's hard to validate it by hand (yes, probably I should stop
    > using XML format for these core data stores).
    >
    > Can anyone see something in the crash log that may help me to figure out
    > what's happening?
    >
    > Many thanks,
    >
    > Martin
    >
    >
    > Date/Time:      2013-05-24 16:22:07.418 +0100
    > OS Version:      Mac OS X 10.6.8 (10K549)
    > Report Version:  6
    >
    > Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
    > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
    > Crashed Thread:  0  Dispatch queue: com.apple.main-thread
    >
    > 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
    > 3  com.apple.CoreData                  0x00007fff898d0c8a
    > -[NSXMLDocumentMap _processDocument] + 282
    > 4  com.apple.CoreData                  0x00007fff898d1037
    > -[NSXMLDocumentMap initWithDocument:forStore:] + 279
    > 5  com.apple.CoreData                  0x00007fff898d33c0
    > -[NSXMLObjectStore
    > initWithPersistentStoreCoordinator:configurationName:URL:options:] + 1248
    > 6  com.apple.CoreData                  0x00007fff89847137
    > -[NSPersistentStoreCoordinator
    > addPersistentStoreWithType:configuration:URL:options:error:] + 711
    > 7  com.apple.AppKit                    0x00007fff88db5b90
    > -[NSPersistentDocument
    > configurePersistentStoreCoordinatorForURL:ofType:modelConfiguration:storeOptions:error:]
    > + 255
    > 8  com.bobsoft.TeXnicle                0x000000010000b5e1 0x100000000 +
    > 46561
    > 9  com.apple.AppKit                    0x00007fff89033d1e
    > -[NSPersistentDocument(NSDeprecatedInternal)
    > _configurePersistentStoreCoordinatorForURL:ofType:error:] + 183
    > 10  com.apple.AppKit                    0x00007fff88db57bb
    > -[NSPersistentDocument readFromURL:ofType:error:] + 124
    > 11  com.apple.AppKit                    0x00007fff88c8830e -[NSDocument
    > initWithContentsOfURL:ofType:error:] + 265
    > 12  com.apple.AppKit                    0x00007fff88c93b88
    > -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] + 332
    > 13  com.apple.AppKit                    0x00007fff88c93978
    > -[NSDocumentController openDocumentWithContentsOfURL:display:error:] + 734
    > 14  com.bobsoft.TeXnicle                0x0000000100121028 0x100000000 +
    > 1183784
    > 15  com.apple.AppKit                    0x00007fff88aaeeda -[NSApplication
    > sendAction:to:from:] + 95
    > 16  com.apple.AppKit                    0x00007fff88aaee39 -[NSControl
    > sendAction:to:] + 94
    > 17  com.apple.AppKit                    0x00007fff88b3a84b -[NSCell
    > trackMouse:inRect:ofView:untilMouseUp:] + 1715
    > 18  com.apple.AppKit                    0x00007fff88b6b37a -[NSButtonCell
    > trackMouse:inRect:ofView:untilMouseUp:] + 555
    > 19  com.apple.AppKit                    0x00007fff88b392f5 -[NSControl
    > mouseDown:] + 624
    > 20  com.apple.AppKit                    0x00007fff88a533a7 -[NSWindow
    > sendEvent:] + 5409
    > 21  com.apple.AppKit                    0x00007fff88988afa -[NSApplication
    > sendEvent:] + 4719
    > 22  com.apple.AppKit                    0x00007fff8891f6de -[NSApplication
    > run] + 474
    > 23  com.apple.AppKit                    0x00007fff889183b0
    > NSApplicationMain + 364
    > 24  com.bobsoft.TeXnicle                0x0000000100002082 0x100000000 +
    > 8322
    > 25  com.bobsoft.TeXnicle                0x0000000100002054 0x100000000 +
    > 8276
    >

    --
    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/
  • 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

    What if the file contains characters that can't be read given the file encoding being used by Core Data? Inspecting the file by hand, I couldn't see anything suspicious, but I couldn't swear to it.

    Many thanks,

    Martin

    On 24, May, 2013, at 06:36 PM, Jens Alfke <jens...> wrote:

    >
    > On May 24, 2013, at 9:11 AM, Martin Hewitson <martin.hewitson...> wrote:
    >
    >> The crash seems to be something to do with the XML file, but the file is >6000 lines long, so it's hard to validate it by hand
    >
    > There are automatic validators, including an online one run by the W3C. I can’t remember the URL but it should be pretty easy to find.
    >
    > —Jens
  • On 24 May 2013, at 18:31, Martin Hewitson <martin.hewitson...> 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
  • 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
    <mdrawford...>

    On Fri, May 24, 2013 at 11:15 AM, Chris Ridd <chrisridd...> wrote:

    >
    > On 24 May 2013, at 18:31, Martin Hewitson <martin.hewitson...>
    > 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
    >

    --
    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/
  • On May 24, 2013, at 08:15 PM, Chris Ridd <chrisridd...> wrote:

    >
    > On 24 May 2013, at 18:31, Martin Hewitson <martin.hewitson...> 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?

    OK, I've followed up on this. There is one attribute in my core data model which is defined as a 64-bit integer. So I checked all occurrences of this in the xml file. They all look fine. I also checked all other integer types in the XML file (int32 and int16) and they look fine too.

    >
    > Try setting a breakpoint on strtoull_l and see what kind of arguments it is getting.

    OK, I far from being expert on using lldb, so how to I do this? I made a symbolic breakpoint on strtoull_l but Xcode doesn't show any local variables - how do I get to see the arguments being passed?

    Many thanks!

    Martin
  • On 25 May 2013, at 5:02 AM, Martin Hewitson <martin.hewitson...> wrote:

    > On May 24, 2013, at 08:15 PM, Chris Ridd <chrisridd...> wrote:
    > …
    >> Try setting a breakpoint on strtoull_l and see what kind of arguments it is getting.
    >
    > OK, I far from being expert on using lldb, so how to I do this? I made a symbolic breakpoint on strtoull_l but Xcode doesn't show any local variables - how do I get to see the arguments being passed?

    You want TN2124, "Mac OS X Debugging Magic" <http://developer.apple.com/library/mac/#technotes/tn2124/_index.html>, in the Some Assembly Required section. It shows how you can use the ABI to pull arguments.

    There will probably be a lot of calls, so I'd set the breakpoint to not pause the program, and attach debugger commands to print the argument values. The transcript will be huge, but the only report you're interested in is the last one.

    There's probably something awesome you can do with DTrace, which I'd turn to if the lldb approach didn't work, but I don't have the chops to suggest a script off the top of my head.

    — F

    --
    Fritz Anderson
    Xcode 4 Unleashed: 4.5 supplement for free!
    http://www.informit.com/store/xcode-4-unleashed-9780672333279
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today