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?

- Jon

On Dec 6, 2019, at 12:46 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

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




Steve Mills
 

On Dec 6, 2019, at 13:53:12, Jon Gotow <gotow@stclairsoft.com> wrote:

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.
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.

On Dec 6, 2019, at 12:57 PM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

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.