CPU max utilization issue on MacOS when using combat tracker is duplicatable

[sstarsslayer]

TL;DR: Each Mac players' FGU CPU utilization jumps 100% higher each combat-round until nearing max and becoming less playable.
See: DMsProcessMonitor.png

This issue, or similar, has been around for months. It almost always affects only players but I can now also duplicate on DM machine. The game runs, sometimes for hours, but becomes less playable as the CPU goes higher and higher until they quit and rejoin. I've spoken before about the issue but didn't have the steps to duplicate. I am now able to duplicate right away every time.
I am loading no extensions, loading no modules, sharing no modules. Running a 5E ruleset. Direct non-cloud option for connections. Some players are Windows users and are not affected. Not opening any images and not using LOS. I made a copy of the problem campaign to test with but I have experienced this on more than one campaign and seen it affect at least 4 different machines running different MacOS versions and different hardware. I will attach the campaign I am doing this in because I wasn't yet able to get a blank campaign to do it. Set the process monitors to refresh quickly and see that all the Mac player machines' cpu utilizations are at about 25% and the DM's machine is steady at about 50%. In the combat tracker on the DM machine, I repeatedly click next-turn - stopping just before the known problem PC record, I observe that the CPU utilization is the same as before, on all machines. When I click next-turn again, all Mac users go from 25% to 125%! The DM machine remains unchanged. Repeat and they will go from 125% to 225%. Cycle through several more rounds. 8-core machines will max out short of 800% utilization shown for the FGU process and other machines will near 1600%, etc. It will not come back down. At that point, they often can continue playing and just shrug off the lag but other apps, such as Discord, usually become noticeably non-performant, prompting them to exit and restart FGU. They will then be steady at 25% again and the hardware temperature returns to normal. To be clear though, this is still an issue even when no other apps are running.

I later added some random PC records to the combat tracker which do not have an owner. Some are blank and some are not. Now all those records trigger the escalating CPU issue, but only for the DM machine this time - even without connecting any players. The player machines stay steady until reaching the known problem record. I released player ownership on the problem record and took a different one as a player. Now the problem record has changed to that one affecting players. Strange because it triggers for all players, not just the one who owns it. The unowned records still only affect the DM. NPC records, such a familiars, are problem-free also.

[Star Drayke]

I had exactly the same issue tonight, it gets unplayable really.
Screen Shot 2020-09-16 at 8.37.04 PM.png

[Moon Wizard]

Just wanted to thank @sstarsslayer for the specific test campaign, and helping us to narrow it down. I was able to finally track the specific issue down to a bad Mac .Net implementation of one of the .Net APIs. Since it was in a place I wouldn't have looked normally and didn't show up in the profiler, we had a lot of trouble identifying this one. A fix for this specific issues will be in the next release build.

Regards,
JPG

[sstarsslayer]

Just wanted to thank @sstarsslayer for the specific test campaign, and helping us to narrow it down. I was able to finally track the specific issue down to a bad Mac .Net implementation of one of the .Net APIs. Since it was in a place I wouldn't have looked normally and didn't show up in the profiler, we had a lot of trouble identifying this one. A fix for this specific issues will be in the next release build.

Regards,
JPG

Hallelujah!