App Crashing on MacOS 10.13.4

General
1

The app that I sell (Lightwright 6) is running fine on Sierra and earlier versions of MacOS, but some of my users have it crashing unpredictably on High Sierra (10.13.4). Lightwright is built using Xojo 2016r3.

Looking at the crash logs, the crash is always the same:

Application Specific Information:
Assertion failed: (mach_vm_map(mach_task_self(), &address, size, 0, VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 0, false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function backing_map, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-312.50/SkyLight/Services/Windows/CGSBackingStore.c, line 191.

Is this something that I can fix, or is it a problem with High Sierra? I haven’t a clue what the crash really means, hopefully better minds than mine can help puzzle this out…

Here is part of a crash log a user sent me (thread 0 only) . Other crashes take slightly different code paths, but arrive at the same place when they crash -

Process: Lightwright 6 [3663]
Path: /Applications/Lightwright 6.app/Contents/MacOS/Lightwright 6
Identifier: com.mckernon.lightwright6
Version: 6.0.16 build 185 (6.0.16.3.185)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Lightwright 6 [3663]
User ID: 501

Date/Time: 2018-05-10 23:09:33.892 -0700
OS Version: Mac OS X 10.13.4 (17E202)
Report Version: 12
Anonymous UUID: 77973F41-8E0E-7A36-BD04-C4AB47FA1D93

Sleep/Wake UUID: 61DFB82D-7B97-42A1-A9E5-F115ED9BA313

Time Awake Since Boot: 22000 seconds
Time Since Wake: 16000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
Assertion failed: (mach_vm_map(mach_task_self(), &address, size, 0, VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 0, false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function backing_map, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-312.50/SkyLight/Services/Windows/CGSBackingStore.c, line 191.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0xa7550eda __pthread_kill + 10
1 libsystem_pthread.dylib 0xa7708427 pthread_kill + 363
2 libsystem_c.dylib 0xa749f956 abort + 133
3 libsystem_c.dylib 0xa7469ead __assert_rtn + 305
4 com.apple.SkyLight 0xa4623789 backing_map + 588
5 com.apple.SkyLight 0xa45c23de lock_window_backing + 462
6 com.apple.SkyLight 0xa45ee442 SLSDeviceLock + 51
7 com.apple.AppKit 0x914fcd2c lock_device + 41
8 com.apple.AppKit 0x914d3a46 NSCGSWindowBackingStoreMark__block_invoke + 893
9 com.apple.AppKit 0x9149fb00 NSCGSTransactionRunPreCommitActionsForOrder + 220
10 com.apple.AppKit 0x9149fa14 NSCGSTransactionRunPreCommitActions + 24
11 com.apple.AppKit 0x9149f9ed __39+[_NSCGSTransaction currentTransaction]_block_invoke + 41
12 com.apple.QuartzCore 0x9c2ff0a5 CA::Transaction::run_commit_handlers(CATransactionPhase) + 45
13 com.apple.QuartzCore 0x9c2fe5cd CA::Context::commit_transaction(CA::Transaction*) + 1581
14 com.apple.QuartzCore 0x9c2fdcff CA::Transaction::commit() + 459
15 com.apple.AppKit 0x91c50b66 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 465
16 com.apple.CoreFoundation 0x937977a6 _runLoopObserverWithBlockContext + 22
17 com.apple.CoreFoundation 0x937974b6 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 22
18 com.apple.CoreFoundation 0x937973d2 __CFRunLoopDoObservers + 498
19 com.apple.CoreFoundation 0x9377a81d __CFRunLoopRun + 1661
20 com.apple.CoreFoundation 0x93779e71 CFRunLoopRunSpecific + 641
21 com.apple.CoreFoundation 0x93779bda CFRunLoopRunInMode + 122
22 com.apple.HIToolbox 0x92d7737b RunCurrentEventLoopInMode + 321
23 com.apple.HIToolbox 0x92d76f5f ReceiveNextEventCommon + 454
24 com.apple.HIToolbox 0x92d76d7b _BlockUntilNextEventMatchingListInModeWithFilter + 71
25 com.apple.AppKit 0x91379b2d _DPSNextEvent + 2101
26 com.apple.AppKit 0x91aebe8c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2859
27 com.apple.AppKit 0x91aeb359 -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] + 134
28 com.xojo.XojoFramework 0x065281e6 0x64e6000 + 270822
29 com.apple.AppKit 0x91681e22 -[NSView _getNextResizeEventFromMask:invalidatingLiveResizeCacheIfNecessary:] + 89
30 com.apple.AppKit 0x9168146c -[NSWindow(NSWindowResizing) _resizeWithEvent:] + 1543
31 com.apple.AppKit 0x91680e5a -[NSTitledFrame resizeWithEvent:] + 60
32 com.apple.AppKit 0x91bb8e70 -[NSTitledFrame attemptResizeWithEvent:] + 168
33 com.apple.AppKit 0x91595c80 -[NSThemeFrame handleMouseDown:] + 257
34 com.apple.AppKit 0x91595ee1 -[NSThemeFrame mouseDown:] + 37
35 com.apple.AppKit 0x91c912b4 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 5327
36 com.apple.AppKit 0x91c8f24f -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 6621
37 com.apple.AppKit 0x91c8d4c0 -[NSWindow(NSEventRouting) sendEvent:] + 475
38 com.xojo.XojoFramework 0x0653835f 0x64e6000 + 336735
39 com.apple.AppKit 0x91aea2d1 -[NSApplication(NSEvent) sendEvent:] + 2657
40 com.xojo.XojoFramework 0x065280e6 0x64e6000 + 270566
41 com.xojo.XojoFramework 0x06528122 0x64e6000 + 270626
42 com.mckernon.lightwright6 0x00190e05 Delegate.Invoke%% + 34
43 com.mckernon.lightwright6 0x00073ad4 Application._CallFunctionWithExceptionHandling%%op + 248
44 com.xojo.XojoFramework 0x06694b1a 0x64e6000 + 1764122
45 com.xojo.XojoFramework 0x06528058 0x64e6000 + 270424
46 com.apple.AppKit 0x9136eac8 -[NSApplication run] + 838
47 com.xojo.XojoFramework 0x06694bba 0x64e6000 + 1764282
48 com.xojo.XojoFramework 0x06692d94 RuntimeRun + 49
49 com.mckernon.lightwright6 0x001637b8 REALbasic._RuntimeRun + 34
50 com.mckernon.lightwright6 0x05e3ffe5 _Main + 295
51 com.mckernon.lightwright6 0x05e37ce6 main + 36
52 com.mckernon.lightwright6 0x05e86b2b start + 53

2

What does your delegate do? Unfortunately, can’t tell much about your XOJO code because it isn’t until line 38 that we see any XOJO framework or app methods. Not much between the main app event loop and your delegate call.

Are the users trying to do a window resize when the crash happens?

It looks like a window resize mousedrag is happening in AppKit. Something in the XOJO setup prior to that event is leaving the underlying OS crash.

3

No delegates at all that I’m aware of. Here’s another example, no mouse click -

Process: Lightwright 6 [11969]
Path: /Applications/Lightwright 6.app/Contents/MacOS/Lightwright 6
Identifier: com.mckernon.lightwright6
Version: 6.0.16 build 185 (6.0.16.3.185)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Lightwright 6 [11969]
User ID: 501

Date/Time: 2018-05-11 13:23:55.123 -0700
OS Version: Mac OS X 10.13.4 (17E202)
Report Version: 12
Anonymous UUID: 77973F41-8E0E-7A36-BD04-C4AB47FA1D93

Sleep/Wake UUID: 8BEEFB0F-E0BD-4C92-95D6-BB52BA6ACD13

Time Awake Since Boot: 31000 seconds
Time Since Wake: 7100 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
Assertion failed: (mach_vm_map(mach_task_self(), &address, size, 0, VM_FLAGS_ANYWHERE | VM_MAKE_TAG(VM_MEMORY_COREGRAPHICS_BACKINGSTORES), port, 0, false, prot, prot, VM_INHERIT_SHARE) == KERN_SUCCESS), function backing_map, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-312.50/SkyLight/Services/Windows/CGSBackingStore.c, line 191.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0xa7550eda __pthread_kill + 10
1 libsystem_pthread.dylib 0xa7708427 pthread_kill + 363
2 libsystem_c.dylib 0xa749f956 abort + 133
3 libsystem_c.dylib 0xa7469ead __assert_rtn + 305
4 com.apple.SkyLight 0xa4623789 backing_map + 588
5 com.apple.SkyLight 0xa45c2517 lock_window_backing + 775
6 com.apple.SkyLight 0xa45ee442 SLSDeviceLock + 51
7 com.apple.AppKit 0x914fcd2c lock_device + 41
8 com.apple.AppKit 0x914d3a46 NSCGSWindowBackingStoreMark__block_invoke + 893
9 com.apple.AppKit 0x9149fb00 NSCGSTransactionRunPreCommitActionsForOrder + 220
10 com.apple.AppKit 0x9149fa14 NSCGSTransactionRunPreCommitActions + 24
11 com.apple.AppKit 0x9149f9ed __39+[_NSCGSTransaction currentTransaction]_block_invoke + 41
12 com.apple.QuartzCore 0x9c2ff0a5 CA::Transaction::run_commit_handlers(CATransactionPhase) + 45
13 com.apple.QuartzCore 0x9c2fe5cd CA::Context::commit_transaction(CA::Transaction*) + 1581
14 com.apple.QuartzCore 0x9c2fdcff CA::Transaction::commit() + 459
15 com.apple.AppKit 0x91c50b66 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 465
16 com.apple.CoreFoundation 0x937977a6 _runLoopObserverWithBlockContext + 22
17 com.apple.CoreFoundation 0x937974b6 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 22
18 com.apple.CoreFoundation 0x937973d2 __CFRunLoopDoObservers + 498
19 com.apple.CoreFoundation 0x9377a81d __CFRunLoopRun + 1661
20 com.apple.CoreFoundation 0x93779e71 CFRunLoopRunSpecific + 641
21 com.apple.CoreFoundation 0x93779bda CFRunLoopRunInMode + 122
22 com.apple.HIToolbox 0x92d7737b RunCurrentEventLoopInMode + 321
23 com.apple.HIToolbox 0x92d76f5f ReceiveNextEventCommon + 454
24 com.apple.HIToolbox 0x92d76d7b _BlockUntilNextEventMatchingListInModeWithFilter + 71
25 com.apple.AppKit 0x91379b2d _DPSNextEvent + 2101
26 com.apple.AppKit 0x91aebe8c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2859
27 com.apple.AppKit 0x91aeb359 -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] + 134
28 com.xojo.XojoFramework 0x065271e6 0x64e5000 + 270822
29 com.xojo.XojoFramework 0x0652722f 0x64e5000 + 270895
30 com.mckernon.lightwright6 0x00190e05 Delegate.Invoke%% + 34
31 com.mckernon.lightwright6 0x00073ad4 Application._CallFunctionWithExceptionHandling%%op + 248
32 com.xojo.XojoFramework 0x06693b1a 0x64e5000 + 1764122
33 com.xojo.XojoFramework 0x06527187 0x64e5000 + 270727
34 com.apple.AppKit 0x9136ea7d -[NSApplication run] + 763
35 com.xojo.XojoFramework 0x06693bba 0x64e5000 + 1764282
36 com.xojo.XojoFramework 0x06691d94 RuntimeRun + 49
37 com.mckernon.lightwright6 0x001637b8 REALbasic._RuntimeRun + 34
38 com.mckernon.lightwright6 0x05e3ffe5 _Main + 295
39 com.mckernon.lightwright6 0x05e37ce6 main + 36
40 com.mckernon.lightwright6 0x05e86b2b start + 53

4

This is deep in the bowels of macOS and a question for Sam because of his knowledge of the macOS drawing stuff.

Don’t use such an old version of Xojo. That would be my first try.

Can you find out where in your code the app crashes?

And then you can try 64bit instead of 32bit.

5

Well this is interesting…

No crashes here on my Mac running MacOS 10.13.4, but Console is going crazy with signpost error logs. This is WITHOUT running your app.

error 22:03:04.591852 -0700 signpost_notificationd 0 is not a valid connection ID.
default 22:03:04.591953 -0700 signpost_notificationd Invalid Connection ID 0
error 22:03:04.592169 -0700 signpost_notificationd 0 is not a valid connection ID.
default 22:03:04.592244 -0700 signpost_notificationd Invalid Connection ID 0
error 22:03:04.592498 -0700 signpost_notificationd 0 is not a valid connection ID.
default 22:03:04.592574 -0700 signpost_notificationd Invalid Connection ID 0

IIRC signpost has some relationship to skylight

6

I would definitely ping @Sam Rowlands for help.

7

Reading the crash reports is pretty much guessing what’s going on, yes it’s deep in the framework and yes it looks like a graphic issue, if I understand it correctly its a memory issue within a ‘private’ framework that’s responsible for managing the ‘buffer’ (backing store) of the window.

Two + One things.

  1. Are you using any declares to alter the Window or controls within the window, any animation?
  2. Are you using OpenGL?
  3. If I am honest, this is probably the typical Sierra/High Sierra graphics issue where the installer/updater hasn’t correctly updated the graphics drivers. This is my assumption, in similar cases users have found relief by performing a “Clean Install”.

You should NEVER assume that the fault is 100% Apple (90% is a more correct), so if you’re using any declares, disable them and work up. If you’re using OpenGL, say bye-bye as I wouldn’t expect any bugs in OpenGL to even get looked at now.

8

[quote=387476:@Sam Rowlands]Are you using any declares to alter the Window or controls within the window, any animation?
Are you using OpenGL?[/quote]

Just three declares, no animation, and no OpenGL.

These are the declares:

[code]#if TargetMacOS

'This code prevents windows from going to full screen mode in El Capitan and later

Declare Function collectionBehavior Lib "AppKit" Selector "collectionBehavior" ( obj As Integer ) As UInteger
Declare Sub setCollectionBehavior Lib "AppKit" Selector "setCollectionBehavior:" ( obj As Integer, value As UInteger )
Const NSWindowCollectionBehaviorFullScreenAuxiliary As UInteger = 256

Dim behavior As UInteger = collectionBehavior(Self.Handle)
setCollectionBehavior(Self.handle, behavior Or NSWindowCollectionBehaviorFullScreenAuxiliary)

#Endif[/code]

[code]#if targetCocoa

dim f as FolderItem

f=Self.MyShow.Filespec
if f <> Nil and f.Exists Then
  declare sub setTitleWithRepresentedFilename lib "Cocoa.framework" selector "setTitleWithRepresentedFilename:" (id as Ptr, filepath as CFStringRef)
  setTitleWithRepresentedFilename Ptr(Self.Handle), f.NativePath
end if

#endif[/code]

#if TargetMacOS Declare sub flush lib "Cocoa" selector "flush" (classref as ptr) Declare function NSClassFromString lib "Cocoa" (classname as CFStringRef) as ptr flush(NSClassFromString("CATransaction")) #Endif

9

I’m using the last declare myself. The second looks doesn’t look very complicated. If a declare is the culprit I’d guess it’s the first one. Why do you need to prevent full screen mode?

10

Myusers got very upset when the menu bar disappeared, and they almost always have another app open at the same time, clicking back and forth between them while working, with both apps windows visible at the same time.

And since I added this code nobody has complained about NOT being able to use it in full screen mode. If they wanted full screen, I’m sure I’d hear about it.

11

Can’t you prevent full screen mode by just unchecking the fullscreen property?

12

This project dates from before that property was available, but also the current language reference says:

“Starting with OS X 10.11 (El Capitan), the Maximize button is treated as a full screen button. You do not have to specifically set FullScreenButton to True. In order for the user to maximize a window rather than put it into Full Screen Mode, they should Option-Click on the Maximize button or double-click the title bar.”

So this declare is needed so that the user doesn’t have to option+click to just maximize the window. Or am I misreading this?

13

I use the exact same declare (as an option) and I’ve even had a couple of users thank me for adding it as an option (which Apple should have done in the first place).

Nope. Which irks the oldies (generally people who use the macOS to make money), meanwhile the people who use a mac as a Touchless iPad love it.

No, you understand it just right, we as developers have to do extra work to disable the ‘new’ features that we and our customers don’t want.

  1. I don’t think it would cause a problem. There is a better way; but it’s more work.

  2. THIS. Why are you using this declare? The reason I ask is because this declare is manipulating the Core Animation ‘layer-tree’ and the crashes are occurring in the CoreAnimation framework (or framework within a framework). Try disabling it, but please tell me why you’re using this, maybe there’s a better way to accomplish what you’re doing.

I also wonder if it’s 1) as ironically the apps that are crashing for my customers also features this declare; I mean technically it shouldn’t, but you never know any more.

14

About two years ago (El Capitan?), there was a problem with windows showing black at first, then finally drawing their contents. Following the forum postings, I added this code and it solved the problem.

Here are some relevant snippets that date from the forum discussion back then:

[quote]@Joe Ranieri Unification of AppKit and CoreAnimation display cycles
AppKit deferred layout and display now occur at the same time as CoreAnimation deferred layout and display. AppKit layout and drawing operations between +[NSAnimationContext beginGrouping] and +[NSAnimationContext endGrouping] will be treated as an atomic unit (this also applies to +[CATransaction begin] and +[CATransaction commit].) This can be used in place of NSDisableScreenUpdates and NSEnableScreenUpdates. The use of these two functions is discouraged. Likewise, it should no longer be necessary to use +[NSWindow disableScreenUpdatesUntilFlush] (its use is also discouraged.)

@Sam Rowlands
This must be why apps draw black windows, which then go white, or draw shadows long before the content… El Cap really has some weird visual artifacts and issues.
Ironically I’ve been using NSDisableScreenUpdates & NSEnableScreenUpdates to mop up this mess!

@jim mckay 14 May 2016

My suspicion is that the window layer and drop shadow are rendered in a separate thread, while the content is rendered on the main thread. If the main thread is blocking, the window layer renders the shadow and then requests the contentView to render and blocks until the view is rendered (when the main runloop completes?). It seems Apple has moved a lot of stuff into threads to improve the responsiveness of app windows and built in controls, like checkbox animations.
Place the following in the open event of a new project with no default window set and you’ll see the plain window. The red Background appears after the blocking loop exits.
Comment out the line beginning with “flush” and you’ll get the black “Window” until the loop exits and then the red.

Window1.Show

Declare sub flush lib “Cocoa” selector “flush” (classref as ptr)
declare Function NSClassFromString lib “Cocoa” (classname as CFStringRef) as ptr

flush(NSClassFromString(“CATransaction”))

dim t as integer=Ticks
while ticks-t<200
wend

window1.HasBackColor=true
window1.BackColor=&cff0000

Anything running in the main thread could block the “animation”… I think the bug is that the OS should be waiting for the window content to render before rendering anything to screen.[/quote]

So it sounds like I should probably try skipping this code if the user has High Sierra or later.

Thoughts?

15

Yeah don’t do that. Instead, what you should do is to hide the window, do your setting up, then set a timer to fire, which will then show the window. This way the window should display when it’s ready.

I wouldn’t recommend this solution for any system at the moment, instead give the solution I mention above a shot. It should solve the glitches on the older OS versions and shouldn’t cause the crashes on the latest “refined” version of the macOS.

Let me know how it goes.