A session on 2026-09-02 that referenced only 26.3-pre-1 spawned 16 unzip.mojom.Unzipper subprocesses; all 16 aborted (16 core dumps, 17:24:40-45 local). Same signature: uncaught std::bad_function_call unwinding out of RunLauncher into std::terminate -> abort. Verified via the __cxa_exception typeinfo pointer, not by string-matching the core.
The session immediately before it launched 26.3-pre-1 and then 26.2 and produced an identical 16-dump burst, so this is not specific to the pre-release.
One caveat that matters if you try to reproduce it: the crash rate is 100% of Unzipper subprocesses spawned, and 0% when none are spawned - and most launches clean, check:
against the dump count for that window. They have matched exactly every time - 16/16 twice today. My own control: a session with one game launch, zero Unzippers spawned, zero dumps.
Also note coredumpctl reports "--type=zygote" for all of these - zygote-forked children inherit the zygote's argv. The real identity is in --utility-sub-type= in the core.
I still cannot isolate what makes the launcher decide to spawn an Unzipper. I ruled out fresh-download, the natives extraction path, return-to-UI after a game exits, and installProduct itself (one session: one installProduct, zero spawns; another: five installProduct calls, one burst). Happy to run instrumentation if you have something specific in mind.
M8SON
Confirming: yes, still reproduces on 26.3-pre-1 (current latest.snapshot).
Environment: Arch Linux, kernel 7.1.9, launcher 2.6.2. liblauncher.so unchanged
since 2026-08-30.
A session on 2026-09-02 that referenced only 26.3-pre-1 spawned 16
unzip.mojom.Unzipper subprocesses; all 16 aborted (16 core dumps, 17:24:40-45
local). Same signature: uncaught std::bad_function_call unwinding out of
RunLauncher into std::terminate -> abort. Verified via the __cxa_exception
typeinfo pointer, not by string-matching the core.
The session immediately before it launched 26.3-pre-1 and then 26.2 and produced
an identical 16-dump burst, so this is not specific to the pre-release.
One caveat that matters if you try to reproduce it: the crash rate is 100% of
Unzipper subprocesses spawned, and 0% when none are spawned - and most launches
clean, check:
against the dump count for that window. They have matched exactly every time -
16/16 twice today. My own control: a session with one game launch, zero
Unzippers spawned, zero dumps.
Also note coredumpctl reports "--type=zygote" for all of these - zygote-forked
children inherit the zygote's argv. The real identity is in --utility-sub-type=
in the core.
I still cannot isolate what makes the launcher decide to spawn an Unzipper. I
ruled out fresh-download, the natives extraction path, return-to-UI after a game
exits, and installProduct itself (one session: one installProduct, zero spawns;
another: five installProduct calls, one burst). Happy to run instrumentation if
you have something specific in mind.