Mac OS Desktop App hard crashing on 10.13 system

Hi Folks,

I’ve just started receiving a series of crash reports that make no sense here. The crash appears to be occurring deep in the Apple SDK, and I have no visibility into how the Xojo framework interfaces at that level. I’m adding the crash log info to see if anyone has an idea of what’s going on.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreGraphics            0x93d6ac16 aal_create + 42
1   com.apple.CoreGraphics            0x9408b1a1 ripr_Acquire + 124
2   com.apple.CoreGraphics            0x9408b015 RIPRenderPath + 67
3   com.apple.CoreGraphics            0x9417d0e3 ripc_GetClipState + 4659
4   com.apple.CoreGraphics            0x93e58e5f ripc_GetRenderingState + 144
5   com.apple.CoreGraphics            0x93e5b852 ripc_DrawRects + 72
6   com.apple.CoreGraphics            0x93d6a86f CGContextFillRects + 105
7   com.apple.CoreGraphics            0x93d6a801 CGContextFillRect + 122
8   com.apple.coreui                  0xa04e23a3 CUICoreThemeRenderer::DrawBackground(CUIDescriptor const*) + 107
9   com.apple.coreui                  0xa0455f01 CUIRenderer::Draw(CGRect, CGContext*, __CFDictionary const*, __CFDictionary const**) + 1819
10  com.apple.coreui                  0xa04557ab CUIDraw + 254
11  com.apple.HIToolbox               0x92f4560d _HIThemeCUIDrawWithOptions + 116
12  com.apple.HIToolbox               0x92f4557e _HIThemeCUIDrawWithRenderer + 169
13  com.apple.HIToolbox               0x92fc8a30 _HIThemeCUIDraw + 31
14  com.apple.HIToolbox               0x93015331 HIContentView::DrawSelf(short, __HIShape const*, CGContext*) + 753
15  com.apple.HIToolbox               0x92f4061c HIView::SendDraw(short, OpaqueGrafPtr*, __HIShape const*, CGContext*) + 394
16  com.apple.HIToolbox               0x92ff6695 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 701
17  com.apple.HIToolbox               0x92ff6951 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 1401
18  com.apple.HIToolbox               0x92ff5d41 HIView::DrawComposited(short, OpaqueGrafPtr*, __HIShape const*, unsigned long, HIView*, CGContext*) + 1135
19  com.apple.HIToolbox               0x92ff5886 HIView::Draw(short, OpaqueGrafPtr*, unsigned long) + 56
20  com.apple.HIToolbox               0x92ff5847 HIView::Render(unsigned long, CGContext*) + 33
21  com.apple.HIToolbox               0x92f54554 FlushWindowObject(WindowData*, void**, unsigned char) + 856
22  com.apple.HIToolbox               0x92f53f0d FlushAllBuffers(__CFRunLoopObserver*, unsigned long, void*) + 353
23  com.apple.CoreFoundation          0x93968d76 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 22
24  com.apple.CoreFoundation          0x93968c92 __CFRunLoopDoObservers + 498
25  com.apple.CoreFoundation          0x9394b6f6 CFRunLoopRunSpecific + 470
26  com.apple.CoreFoundation          0x9394b50a CFRunLoopRunInMode + 122
27  com.apple.HIToolbox               0x92f4a42b RunCurrentEventLoopInMode + 321
28  com.apple.HIToolbox               0x92f4a00f ReceiveNextEventCommon + 454
29  com.apple.HIToolbox               0x930c65e6 ReceiveNextEvent + 68
30  rbframework.dylib                 0x013de6c4 0x1357000 + 554692
31  rbframework.dylib                 0x013de2d9 0x1357000 + 553689
32  rbframework.dylib                 0x013df1f6 0x1357000 + 557558
33  com.tolisgroup.bru-pe             0x000197a2 Delegate.Invoke%% + 34
34  com.tolisgroup.bru-pe             0x000b4572 Application._CallFunctionWithExceptionHandling%%o<Application>p + 248
35  rbframework.dylib                 0x013df024 0x1357000 + 557092
36  rbframework.dylib                 0x013df3d0 0x1357000 + 558032
37  rbframework.dylib                 0x013aa6a2 RuntimeRun + 50
38  com.tolisgroup.bru-pe             0x0021484d REALbasic._RuntimeRun + 34
39  com.tolisgroup.bru-pe             0x00003f06 _Main + 257
40  com.tolisgroup.bru-pe             0x0000253c % main + 36
41  com.tolisgroup.bru-pe             0x00fed6f9 _start + 116
42  com.tolisgroup.bru-pe             0x00fed64f start + 43

I presume you’ve restarted the machine. These kind of crashes are common on 10.13 (due to it being fully baked), they tend to go away when the machine is either restarted, the OS updated or reverted back to a stable build.

I’ve even had some error reports where the OS claims that API is not available, restarting the machine fixes that.

Now CoreGraphics crashes can be related to crappy graphics card drivers, if these continue on a certain machine, doing a clean install will solve that (if it’s related to a graphics card).

I have my suspicion that the installer for High Sierra is not always able to update some kexts, so it silently leaves incompatible ones behind, which like a duct tape on a tire will hold, but under stress…

[quote=367503:@Sam Rowlands]I presume you’ve restarted the machine. These kind of crashes are common on 10.13 (due to it being fully baked), they tend to go away when the machine is either restarted, the OS updated or reverted back to a stable build.

I’ve even had some error reports where the OS claims that API is not available, restarting the machine fixes that.

Now CoreGraphics crashes can be related to crappy graphics card drivers, if these continue on a certain machine, doing a clean install will solve that (if it’s related to a graphics card).

I have my suspicion that the installer for High Sierra is not always able to update some kexts, so it silently leaves incompatible ones behind, which like a duct tape on a tire will hold, but under stress…[/quote]
This is probably right on - after digging deeper with the users reporting the issue, they are also seeing crashes with FCP X and Premiere Pro. To quote on of my Windows core engineers - SIGH! :S

Look on the bright side, at least you and the customer is aware that it’s not your fault. I have been advising customers who’re having these issues (and when they confirm that other apps are unreliable now) to Product Feedback - Apple and complain there about the degradation in Apple’s software quality. Apple doesn’t seem to care what us developers say, but if all the frustrated users complained, they’d be snowed under (hell if all the people complaining on Reddit would send in feedback, this would probably break Apple’s servers alone).

Got a crash from a user:

Thread 11 Crashed:: Dispatch queue: com.apple.root.default-qos
0 com.apple.QuartzCore 0x9c80b7ba magazine_dealloc_ + 260
1 com.apple.QuartzCore 0x9c80ba46 x_mem_dealloc_bucket + 128
2 com.apple.QuartzCore 0x9c823fa9 CA::Render::Shmem::~Shmem() + 27
3 com.apple.QuartzCore 0x9c81557d CA::Render::Object::unref() const + 227
4 com.apple.QuartzCore 0x9c81f1d6 CABackingStoreDeleteBuffer(CABackingStoreBuffer*) + 41
5 com.apple.QuartzCore 0x9c81ff9b CABackingStoreCollect_(double, bool) + 551
6 com.apple.QuartzCore 0x9c81fd27 CABackingStoreCollect + 32
7 com.apple.QuartzCore 0x9c81fcb6 async_collect_callback(void*) + 47
8 libdispatch.dylib 0xa752c645 _dispatch_queue_override_invoke + 779
9 libdispatch.dylib 0xa7521157 _dispatch_root_queue_drain + 660
10 libdispatch.dylib 0xa7520e71 _dispatch_worker_thread3 + 100
11 libsystem_pthread.dylib 0xa77ddfdc _pthread_wqthread + 1356
12 libsystem_pthread.dylib 0xa77dda6a start_wqthread + 34

Can you guess the reason for the crash? The file was on a webdav drive. According to the user:

[quote]The webdav issue was causing the volume to dismount while being written to,
so basically the file system disappeared in the middle of a write
operation, which was causing crashes not only in your app but others as
well (which is how I realized it).[/quote]

Isn’t it the job of the OS to say “hey, the file you wanted to write to isn’t there anymore”?

Unfortunately - losing the physical drive did not invalidate the file handle, and I suspect that Apple Isn’t doing things right there in some cases. Start writing to a physically attached device - USB, TB, etc.) and pull the plug on the drive. I’ve found that Apple handles that fairly well. A network attached volume, on the other hand, doesn’t have a physical layer for the kernel to interact with, so if the file handler for the filesystem being used isn’t set up to handle the loss of the path, that could cause a crash as the app tries to write to a no-longer mapped file handle. I would be curious if the user’s system was using an Apple API or an API provided by the remote hosting service. We also see this type of unhandled event with a lot of FUSE layer filesystems - such as LTFS. We can cause Finder to glitch completely when copying files to an LTFS tape.