Mojave large NSView crashes MacOS

I have a NSView contained in a NSScrollView of size 32768 x 32768 that is drawing many (multiple 100) complex bezier curves. The view is scaled to about x0.05.


You can see what this looks like in practise in the screenshots https://itunes.apple.com/gb/app/trout/id445221676?mt=12


None of the views or its subviews are CALayer backed. I do observe the automatic conversion to CATiledLayer occuring in the parent scroll view.


When the app launches and the NSWindow restores state I am seeing the memory profile for the app rapidly soar to multiple GB in the space of circa 30 seconds. Its a heisenbug that doesnt appear when I profile in Instruments.


If i do nothing the entire machine locks up permanently (no mouse activity, no keyboard response) and requires a hard restart via the power button. Even a timed `sleep 60 && killall -9 MyProcess` can't help.


This isnt a grey screen of death. Even MacOS doesnt acknowledge that a system crash occured after restart.


The crash doesnt happen with other documents with less curves to draw.


I can recover if I manually stop the run before the memory profile rises too high.


This doesnt seem to happen in a release build but im reluctant to send to the store with the possiblilty of causing my customers machine to fully crash.


Any ideas for debugging switches relating to NSView ? Or what is happening.

Replies

I managed to observe the phenomenum in instruments.


There seems to be many (100's of) persistent allocations of circa 1.25MB in CA::Render::Shmem::new_shmem(unsigned long)

OK - odd bug


If i called `magnifyToFitRect` too soon after adding the subviews to the `documentView` (my custom view) of the containing NSScrollView I could trigger it with a sufficiently large data set.


Im guessing that some combo of autolayout, CATiledLayer and the change in resolution firing more layout requests causes recursive setNeedsDisplay and om nom.


I will raise a radar if i can create a minimal case.