We don’t have a real fix yet, but in the meantime, as @stone mentioned, you can sidestep the problem by disabling core dumps:
ulimit -c 0
This restores the usual launch time.
Unfortunately a proper fix will take us a little while, so this will still be broken with the next release 2.4.36, which is release testing right now.
For background - this crash has actually been in our Linux app for quite some time. We think what happened is the default crash handling behavior of Arch and Fedora has recently changed, causing the crash dump generation to take macro time. Prior to the update, the application still crashed in the same way, but startup continued uninterrupted. It’s a subprocess that is crashing, which is why the application continues to work.
Specifically, when our application launches, it initializes a python interpreter to support python measurements and high-level analyzers. In the process, Python calls subprocess_fork_exec, and the forked process will frequently crash immediately after that. (Our current lead is that the crash may be caused by the fact that python is running from within an electron process)
We’ve spent a little time researching this crash before, but since it had (until now) zero end user impact, we never prioritized it.
Thanks everyone for your patience, and I’ll share an update as soon as I have one.