macOS: Morph node crasher

[dre]

Hi,

When the Morph node is configured with width / height of 0, this reliably results in either a WindowServer crash or a kernel panic. I’ve attached a simple test case, which I had to fish out of ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information, since every single time the composition loads, the crash occurs. Pro tip: holding shift at login temporarily disables auto-resume.

Not totally sure if this is your bug or Apple’s, but probably both. I don’t know if zero or negative width / height are valid values for the Morph node, but this feels similar to crashes that happen due to improper / incorrect thread group sizes in compute shaders.

Cheers,
-dre

Attachments:

1. morph-node-crasher.circle.zip

[dre]

A couple of additional notes about this situation:

1) Circles would always re-open the problematic document at every launch, even though I have “Close windows when quitting an app” enabled in the General prefpane.

2) Launching Circles with ‘shift’ held does not disable restoring state, as it does for many / most apps (e.g. TextEdit). This suggests to me that Circles is doing its own stuff to re-open documents that were open in the previous session. You can easily reproduce this by creating a new document with any random node, then force quit Circles without saving the document. If you re-open Circles, the document comes back. If you re-open with shift key, the document still comes back.

3) Removing an offending document from ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information is not sufficient to prevent it from being re-opened at next launch. This surprised me and took a little time to figure out. Here’s a hint:

 % plutil -p ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information/xyz.heestand.nodes.circle.plist 
[
  0 => {
    "autosavedContentsBookmark" => {length = 1232, bytes = 0x626f6f6b d0040000 00000410 30000000 ... 94020000 00000000 }
    "recordDate" => 2022-09-11 01:04:44 +0000
    "uniquingNumber" => 1
  }
]

The name autosavedContentsBookmark includes ‘bookmark’, which suggests to me that perhaps this reference is a CFURL, which is significant because a CFURL doesn’t lose track of a file even if you move that file. I had placed the crashing document in the trash, which is how I learned that CFURL is not above rummaging through my garbage. To prove that, prior to launching Circles, I started fs_usage as follows:

sudo date ; sudo stdbuf -o0 fs_usage -w Circles | stdbuf -o0 tee ~/Desktop/circles.fsusage.txt

The first sudo is just to temporarily cache your password, and stdbuf is there to disable buffering which helps when trying to capture log messages that occur immediately before a crash or hang.

After logging back in, examine the file, and sure enough:

...
open /Users/andre/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Saved Application State/xyz.heestand.nodes.circle.savedState/restorecount.plist
getattrlist /Users/andre/.Trash/morph-node-crasher.circle
...

So I emptied the trash, and now Circles can’t open that file because it’s no there (or anywhere else).

[dre]

UGH, gross. I guess WordPress accepts styled text, and I also can’t edit the post to fix the font size. Please believe me when I tell you that I wasn’t intending to use a font that large, maybe it’s some odd interaction with browser scaling… I’m old but not THAT old.

[dre]

oh NO, this is worse than I thought… I’m guessing that my ‘dark mode’ browser extension is somehow leaking styled text into the wordpress form. I’m going to re-post all of the above with that extension disabled.

[dre]

I hope this looks better – I can confirm that this is not styled text as I paste it into the form (see screenshot).

Hi,

When the Morph node is configured with width / height of 0, this reliably results in either a WindowServer crash or a kernel panic. I’ve attached a simple test case, which I had to fish out of ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information, since every single time the composition loads, the crash occurs. Pro tip: holding shift at login temporarily disables auto-resume.

Not totally sure if this is your bug or Apple’s, but probably both. I don’t know if zero or negative width / height are valid values for the Morph node, but this feels similar to crashes that happen when supplying incorrect thread group sizes in Metal compute shaders.

A few additional notes about this situation:

1) Circles would always re-open the problematic document at every launch, even though I have “Close windows when quitting an app” enabled in the General prefpane.

2) Launching Circles with ‘shift’ held does not disable restoring state, as it does for many / most apps (e.g. TextEdit). This suggests to me that Circles is doing its own stuff to re-open documents that were open in the previous session. You can easily reproduce this by creating a new document with any random node, wait a second or two for the autosave file to get written, then force quit Circles without saving the document. If you re-open Circles, the document comes back. If you re-open with shift key held, the document still comes back.

3) Removing an offending document from ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information is *not sufficient* to prevent it from being re-opened at next launch. This surprised me and took a little time to figure out. Here’s a hint:

% plutil -p ~/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Autosave\ Information/xyz.heestand.nodes.circle.plist 
[
  0 => {
    "autosavedContentsBookmark" => {length = 1232, bytes = 0x626f6f6b d0040000 00000410 30000000 ... 94020000 00000000 }
    "recordDate" => 2022-09-11 01:04:44 +0000
    "uniquingNumber" => 1
  }
]

The name autosavedContentsBookmark includes ‘bookmark’, which suggests to me that perhaps this reference is a CFURL, which is significant because a CFURL doesn’t lose track of a file even if you move that file. I had placed the crashing document in the trash, which is how I learned that CFURL is not above rummaging through my garbage. To prove that, prior to launching Circles, I started fs_usage as follows:

sudo date ; sudo stdbuf -o0 fs_usage -w Circles | stdbuf -o0 tee ~/Desktop/circles.fsusage.txt

The first sudo is just to temporarily cache your password, and stdbuf is there to disable buffering which helps when trying to capture log messages that occur immediately before a crash or hang.

After logging back in, examine the file, and sure enough:

...
open /Users/andre/Library/Containers/xyz.heestand.nodes.circle/Data/Library/Saved Application State/xyz.heestand.nodes.circle.savedState/restorecount.plist
getattrlist /Users/andre/.Trash/morph-node-crasher.circle
...

So I emptied the trash, and now Circles no longer crashes after attempting to open that file, which is now gone.

Cheers,
-dre

Attachments:

1. 

   clipboard-viewer.png
   

[dre]

I am forced to conclude that this forum is slightly busted 🙂 I wouldn’t be surprised if lack of https is breaking stuff, since most browsers hate that these days…

I use LetsEncrypt to get free SSL certs for all my personal domains. The key is to set up some automation to renew the certs, because the certificate lifetimes are fairly short (a few months or so).

[Anton Heestand]

Hi, regarding the Morph Pixel Node:
I’m using the MPSImageAreaMin/Max.
Here I set the kernelWidth to 1 + max(width, 0) * 2, to make sure it’s odd. I just now added the max to avoid negative values. Tho a width of 0 (kernelWidth of 1) works for me.

• This reply was modified 1 year, 7 months ago by Anton Heestand.

[Anton Heestand]

Hi, regarding the file life cycle:
I’m using a SwiftUI DocumentGroup with a FileDocument.
Tho the file is a folder (LSTypeIsPackage).
So to access the folder on open I re-save it with:
try configuration.file.write(to: temporaryURL, originalContentsURL: nil)
Maybe this is causing the file not to behave as expected…

[Author]

Posts