I was working on a component character and in the composite was pasting base + accent from one master to the next. Going back to the accent I tried to copy the anchor from one master to another, because the anchor was missing from some masters. I must have failed to actually copy that anchor, though, e.g. mis-clicked. When I then hit cmd+paste Glyphs seems to have pasted the previously selected base + accent components — now within that component itself, thus sending the program down into eternal recursion with only force-quitting as a remedy.
This should probably be an impossible action, even if performed only by accident.
Haha, good that you managed to, because I tried my best to recreate the scenario I described above but couldn’t make it crash — but would have also insisted that was what made the app crash yesterday
Happened to me again. Accidentally pasted horncomb into O while also viewing Ohorn in the in the preview.
Didn’t have console open when it happened, unfortunately, but after hanging unresponsive for a bit you get this:
default 15:38:16.610835 +0300 symptomsd Received CPU usage trigger:
Glyphs[91977] () used 90.00s of CPU over 121.77 seconds (averaging 73%), violating a CPU usage limit of 90.00s over 180 seconds.
default 15:38:16.610695 +0300 kernel process Glyphs[91977] thread 3009543 caught burning CPU! It used more than 50% CPU over 180 seconds (actual recent usage: 73% over ~122 seconds). Thread lifetime cpu usage 2156.776159s, (2085.094308 user, 71.681851 sys) ledger balance: 90004106636 mabs credit: 2138581643309 mabs debit: 2048577536673 mabs limit: 90000000000 mabs period: 180000000000 ns last refill: 121769071535 ns.
Edit: Also, like last time, reopening the crashed autosaved file the supposedly recursive component actually is in the character, so in this case horncomb is inside O, yet this does not seem to cause any significant problems then.