Date
1 - 4 of 4
Crash in Apple code, not mine - what can I do?
|
Steve Mills
A customer sent a crashlog that clearly shows Apple's code is what's crashing on 10.14.6. There's no way I can reproduce it. So what can I do? Just submit a bug to Apple with the crashlog (although it's 10.14.6, so I doubt they care)?
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x00007fff6dc0269d objc_msgSend + 29 1 com.apple.AppKit 0x00007fff41034f8b -[NSDocument _silentlyRecoverableVariantOfSavingError:resaver:] + 40 2 com.apple.AppKit 0x00007fff415c7ce1 __85-[NSDocument(NSDocumentSaving) _saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke.856 + 620 3 com.apple.AppKit 0x00007fff415c9247 __85-[NSDocument(NSDocumentSaving) _saveToURL:ofType:forSaveOperation:completionHandler:]_block_invoke_3.916 + 209 4 com.apple.AppKit 0x00007fff41068079 __62-[NSDocumentController(NSInternal) _onMainThreadInvokeWorker:]_block_invoke_3 + 152 5 com.apple.AppKit 0x00007fff4106a834 ___NSMainRunLoopPerformBlockInModes_block_invoke + 25 6 com.apple.CoreFoundation 0x00007fff434c4ec4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 7 com.apple.CoreFoundation 0x00007fff434885e7 __CFRunLoopDoBlocks + 394 8 com.apple.CoreFoundation 0x00007fff43487d06 __CFRunLoopRun + 1174 9 com.apple.CoreFoundation 0x00007fff4348761e CFRunLoopRunSpecific + 455 10 com.apple.HIToolbox 0x00007fff426e61ab RunCurrentEventLoopInMode + 292 11 com.apple.HIToolbox 0x00007fff426e5ee5 ReceiveNextEventCommon + 603 12 com.apple.HIToolbox 0x00007fff426e5c76 _BlockUntilNextEventMatchingListInModeWithFilter + 64 13 com.apple.AppKit 0x00007fff40a7e77d _DPSNextEvent + 1135 14 com.apple.AppKit 0x00007fff40a7d46b -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361 15 com.apple.AppKit 0x00007fff40a77588 -[NSApplication run] + 699 16 com.apple.AppKit 0x00007fff40a66ac8 NSApplicationMain + 777 17 libdyld.dylib 0x00007fff6f3de3d5 start + 1 -- Steve Mills Drummer, Mac geek |
|
|
|
Jon Gotow
What's the actual cause of the crash? A segmentation fault (SIGSEGV) or some other memory error could be caused by you corrupting memory, handing NSDocumentController a bad object somehow, or some other application error. My experience with crashes in AppKit is that it's usually something I've done prior to the crash that has scrambled memory or corrupted an object. Is the problem reproducible so you can chase down possibilities?
toggle quoted message
Show quoted text
- Jon On Dec 6, 2019, at 12:46 PM, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|
|
Steve Mills
On Dec 6, 2019, at 13:53:12, Jon Gotow <gotow@...> wrote:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00006db9f91b0e58 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [16005] Is the problem reproducible so you can chase down possibilities?Not on my machine. For the customer, he's been able to create and save docs before. But then they all start crashing at some point during save. The document uses CoreData, so much of it is a mystery. I'll see if he can use Console to maybe look for anything that CoreData might be puking out prior to the crash. -- Steve Mills Drummer, Mac geek |
|
|
|
Jon Gotow
Ugh - I don't have a whole lot of experience with CoreData, but it does add a whole lot of possible failure modes. It's tough that you can't reproduce the issue locally - any chance the customer will send you one of their docs that causes the crash? That'd certainly make it easier.
toggle quoted message
Show quoted text
On Dec 6, 2019, at 12:57 PM, Steve Mills via Groups.Io <sjmills@...> wrote: |
|
|