On Linux, two of the launcher's Chromium utility subprocesses --
unzip.mojom.Unzipper and data_decoder.mojom.DataDecoderService -- abort on every
attempt with an uncaught std::bad_function_call thrown inside liblauncher.so. The
launcher swallows the failure, so there is no UI-visible symptom, but each session
leaves one core dump per spawn. Across 9 sessions reconciling exactly against the
coredump log, 96 spawns produced 96 aborts and 0 successes.
Not game-version specific: these are launcher-side processes that never touch the
game. Aborts occur across 26.1.2, 26.1.2-OptiFine and 26.2, and in a session where
no game was launched at all.
Steps to Reproduce
Install the launcher on Linux with systemd-coredump enabled (default on most
distributions).Start the launcher, sign in, use it normally for a minute, then quit.
Compare:
coredumpctl list
grep -c "utility-sub-type=unzip.mojom.Unzipper" ~/.minecraft/launcher_log.txt
grep -c "utility-sub-type=data_decoder" ~/.minecraft/launcher_log.txt
The launcher core dump count equals the sum of those two.
I could not isolate the user action that triggers an unzip or decode request. What
I can show is that whenever the launcher makes either request, that subprocess dies
-- 100% of the time, no partial successes. Launching a game is NOT the factor: one
session launched a game with zero aborts, another produced sixteen without one.
Expected Results
The subprocess starts and does its work; or, failing that, the launcher handles it
without the child aborting.
Observed Results
Each spawn produces one SIGABRT (si_code: SI_TKILL) within seconds, matching 1:1
with a "Will launch a Chromium subprocess ... --utility-sub-type=..." line in
launcher_log.txt. Dumps in each session window vs. spawns logged:
log unzip ddec dumps (dumps should equal unzip+ddec)
log3 16 1 17
log4 16 1 17
log5 0 1 1
log6 0 1 1
log7 16 1 17
log8 16 1 17
log9 0 0 0
log0 16 0 16
current 9 1 10
TOTAL 89 7 96
The two sessions with zero Unzipper spawns and one DataDecoder spawn each produced
exactly one dump, so this is not unzip-specific.
IMPORTANT -- identifying which subprocess died
Every one of these dumps reports "--type=zygote" in coredumpctl info, because a
zygote-forked child inherits the zygote's argv and it is never rewritten. Triaging
by command line alone wrongly concludes the zygote is crashing. The real identity
is in the core, with the --shared-files and --field-trial-handle switches only a
fully launched utility process receives:
$ strings -a core | grep -o -- '--utility-sub-type=[A-Za-z_.]*' | sort -u
--utility-sub-type=data_decoder.mojom.DataDecoderService
Technical Analysis
Crashing thread, symbolized via the Arch Linux debuginfod server. Identical for
both failing services; frames 10-15 are in liblauncher.so with no symbols beyond
the exported RunLauncher:
#3-#5 __GI_abort <- __verbose_terminate_handler <- __cxxabiv1::__terminate
#6 __cxa_call_terminate (ue_header_in=0x55c1e15a81f0) at eh_call.cc:56
#7 __gxx_personality_v0 (actions=6, ...) at eh_personality.cc:692
#8-#9 _Unwind_RaiseException_Phase2 <- _Unwind_Resume (exc=0x55c1e15a81f0)
#10-#14 ?? () from .minecraft/launcher/liblauncher.so
#15 RunLauncher (liblauncher.so + 0x1b270e)
The in-flight exception was recovered from the core. __cxa_exception precedes the
_Unwind_Exception from frame 6, so with sizeof 112 and 32, exceptionType is at
header - 80:
(gdb) x/gx 0x55c1e15a81f0 - 80
0x55c1e15a81a0: 0x00007fdea4cc49e0
(gdb) info symbol 0x00007fdea4cc49e0
typeinfo for std::bad_function_call in .data.rel.ro of /usr/lib/libstdc++.so.6
std::bad_function_call has exactly one cause: an empty std::function was invoked.
It is thrown, never caught, and unwinds out of RunLauncher into std::terminate.
Localizing the defect
Six subprocess kinds run in a normal session. Two fail every time, four never do:
unzip.mojom.Unzipper 89 spawns, 89 aborts (on demand)
data_decoder.mojom.DataDecoderService 7 spawns, 7 aborts (on demand)
network.mojom.NetworkService 8 spawns, 0 aborts (at startup)
storage.mojom.StorageService 8 spawns, 0 aborts (at startup)
audio.mojom.AudioService 8 spawns, 0 aborts (at startup)
renderer / gpu / zygote 40 spawns, 0 aborts (at startup)
The generic child-process path is therefore healthy. This points at the callback
or factory for these two services being left unset in the child, where those for
the others are installed correctly.
Frequency
100% reproducible, across two self-updated liblauncher.so builds (24 and 30 Aug
2026). Not a recent regression.
Impact
No user-visible failure observed -- the launcher recovers, the game starts and
exits normally. But 137 launcher core dumps have reached 2.3 GB in
/var/lib/systemd/coredump here.
I could not verify whether an operation genuinely depending on these services (a
Java runtime install on a clean profile, say) fails too. Here the runtime was
already unpacked, so the failed unzips had no dependent work. Worth checking.
Environment
Launcher core 3.39.31 (865b5652e408aebc2c51f4477b4e3c3d14e843c0), binary 2.6.2,
bootstrap 2.1.3, CEF 127.3.5+g114ea2a+chromium-127.0.6533.120. OS/toolchain in the
Environment field.
Core dumps available on request -- they contain live authentication tokens, so I
would transfer one privately rather than attach it to a public ticket.
Environment
Arch Linux (Omarchy 4.0.1), kernel 7.1.9-arch1-2, Wayland/Hyprland. Launcher core 3.39.31, binary 2.6.2, bootstrap 2.1.3. CEF 127.3.5+chromium-127.0.6533.120. glibc 2.44, libstdc++ 16.2.1. Launcher passes --no-sandbox itself.
Linked issues
is duplicated by 1
Comments 6
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:
grep -c 'utility-sub-type=unzip.mojom.Unzipper' launcher_log.txtagainst 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.
This issue has been reviewed by our team.
Please add new, relevant information if it helps us understand or reproduce the issue. To show that you’re affected, use the vote feature rather than commenting.
If a fix is implemented, it will be listed in our official changelogs.
For major outages or urgent assistance, visit the Minecraft Help Center.
Additional diagnostic evidence from another machine, collected September 14, 2026. This closely matches MCL-26854: the same launcher core/build, std::bad_function_call, repeated Unzipper-related helper aborts, and a game session that continues normally.
MACHINE / SOFTWARE
• Arch Linux x86_64 with Omarchy 4.0.3-1 (a desktop configuration layer), Hyprland 0.56.2-2 / Wayland; current kernel 7.2.3-arch1-3. These OS versions were collected September 14.
• CPU: Intel Core i5-14600K, 20 logical CPUs.
• GPU: NVIDIA GeForce RTX 4060 Ti (AD106); nvidia-utils 610.57.04-1.
• Memory: approximately 32 GB installed (31 GiB reported); 62 GiB swap. No OOM event was found around the investigated crashes.
• Launcher core: 3.39.31, commit 865b5652e408aebc2c51f4477b4e3c3d14e843c0.
• Native launcher: 2.6.2; bootstrap: 2.1.3; installed Arch package: minecraft-launcher 1:2.1.3-3 (Official Minecraft Launcher).
• CEF: 127.3.5+g114ea2a+chromium-127.0.6533.120.
• glibc: 2.44+r24+g16be1518495f-1; gcc-libs/libgcc: 16.2.1+r23+gd564253eb6c8-1.
• liblauncher.so ELF build ID: 35409dcda3832d27a40ffe22c9553529327ecf18.
• minecraft-launcher ELF build ID: 2f91a58a95fa4bafce624f38beebd03105b7e7d0.
• Launcher executable: $HOME/.minecraft/launcher/minecraft-launcher.
• The representative September 12 session launched Minecraft Java Edition 26.2, using the bundled Java runtime beneath $HOME/.minecraft/runtime/java-runtime-epsilon/. I have not tested the latest pre-release for this report.
FREQUENCY / MATCHING STACKS
The system journal contains 304 launcher core-dump entries from September 5–12, 2026. All 304 contain exactly the same six liblauncher.so offsets:
0x1360a3 -> 0x29f2f1 -> 0x29f43d -> 0x29e9c2 -> 0x1e0b06 -> RunLauncher + 0x1b270e.
Counts by date:
2026-09-05: 16
2026-09-06: 32
2026-09-07: 64
2026-09-08: 64
2026-09-09: 32
2026-09-10: 16
2026-09-11: 48
2026-09-12: 32
Total: 304.
Eight selected events were cross-checked against the journal (times CEST, UTC+02):
September 6 20:47:50 — PID 3742
September 7 10:30:44 — PID 3741
September 7 14:37:11 — PID 4083
September 7 18:28:40 — PID 3893
September 7 20:32:48 — PID 4445
September 8 09:23:14 — PID 4258
September 11 10:38:00 — PID 12251
September 12 20:08:33 — PID 3740
All eight have SIGABRT and the same launcher offsets. Multiple prior core inspections recovered std::bad_function_call; identical journal stacks do not independently establish the exception type in every one of the 304 cores.
REPRESENTATIVE SESSION: SEPTEMBER 12
20:07:32 CEST: launcher opened normally from the desktop.
20:07:41 CEST: Minecraft Java 26.2 starting.
20:08:33–20:08:37 CEST: 16 launcher helper processes aborted; representative PID 3740.
The launcher log records 16 requests for --type=utility --utility-sub-type=unzip.mojom.Unzipper during those same seconds. The first two are at 18:08:33.363907652 and 18:08:33.739589764 UTC, and the final request is at 18:08:37.743060068 UTC. Launcher-log timestamps are UTC, two hours behind CEST.
Files beneath webcache2/component_crx_cache, AutofillStates, PKIMetadata, and SafetyTips have matching modification times.
21:10:04 CEST: the game ended normally with exit code 0. Game logging continued after the crash burst; no loss of game progress was observed in the evidence.
CORE EVIDENCE: PID 3740
Signal: SIGABRT, si_code SI_TKILL.
Recorded command:
minecraft-launcher --type=zygote --no-sandbox --enable-crash-reporter=, --change-stack-guard-on-fork=enable --enable-chrome-runtime --user-data-dir=$HOME/.minecraft/webcache2 --log-severity=info --launcherui --workdir=$HOME/.minecraft
The recorded argv says zygote, consistent with the inherited-argv caveat in this issue. On this machine, the Unzipper relationship was established by matching the parent's requests and crash timestamps; I have not independently checked the recovered utility-sub-type argument inside this core.
Main thread stack (module-relative offsets for comparison):
#0 libc.so.6 + 0x9a17c
#1 raise (libc.so.6 + 0x3e5d0)
#2 abort (libc.so.6 + 0x25685)
#3 libstdc++.so.6 + 0x9ac54
#4 libstdc++.so.6 + 0xb581a
#5 __cxa_call_terminate (libstdc++.so.6 + 0x9a459)
#6 __gxx_personality_v0 (libstdc++.so.6 + 0xb4ced)
#7 libgcc_s.so.1 + 0x22043
#8 _Unwind_Resume (libgcc_s.so.1 + 0x22b8b)
#9 liblauncher.so + 0x1360a3
#10 liblauncher.so + 0x29f2f1
#11 liblauncher.so + 0x29f43d
#12 liblauncher.so + 0x29e9c2
#13 liblauncher.so + 0x1e0b06
#14 RunLauncher (liblauncher.so + 0x1b270e)
#15 minecraft-launcher + 0x1ba9e0
#16 minecraft-launcher + 0x49ad9
#17 minecraft-launcher + 0x34ec9
#18 libc.so.6 + 0x27781
#19 __libc_start_main (libc.so.6 + 0x278b9)
#20 _start (minecraft-launcher + 0x36bda)
The exception RTTI name recovered from the C++ exception header was St17bad_function_call (std::bad_function_call). For PID 3740, frame 5 preserved the unwind-header pointer in RBX = 0x559f3de8afc0; reading the typeinfo name through header minus 80 yielded that name. The exception object begins at 0x559f3de8afe0, where its vtable pointer is stored. This was a structured exception-header inspection, not a search for arbitrary strings in process memory.
The other three threads (3741, 3743, 3744) were waiting in pthread_cond_timedwait / pthread_cond_wait with libcef.so frames. NVIDIA libraries were mapped, but none appears in the crashing call stack. The exact launcher callback remains unidentified because launcher debug symbols were unavailable.
REPRODUCTION LIMITS AND IMPACT
Observed during ordinary launcher/game use; no newly controlled clean-profile reproduction has been performed. This data set adds evidence for Unzipper-related aborts; I am not asserting independent confirmation of DataDecoder failures. No package update coincided with the selected crashes, and launcher binary mtimes were September 5, before these investigated events.
On Omarchy, these otherwise unobtrusive helper failures produce clickable “Process crashed” notifications offering AI diagnosis. Repeated sessions led to eight diagnostic chats on this machine, although the child playing Minecraft could continue playing. After collecting the evidence, we excluded Minecraft from those desktop prompts only. Launcher/game configuration and systemd core capture were not changed, and no cache deletion was used to produce or address these observations.
This appears to be the same failure already tracked here, persisting on Omarchy 4.0.3-1 with launcher core 3.39.31. The additional value is the newer machine environment, exact ELF build IDs, 304 matching journal stacks, and timestamp correlation with component-cache updates. Raw core dumps and full launcher logs are not included because they may contain account/session data and game chat; the diagnostic details above use a redacted home path.
Prepared with AI assistance (Codex) from local journal records, launcher logs, and core-dump investigations.
Additional confirmation from a different distribution, with one new failing service
Environment: Debian 13 (trixie), KDE Plasma (X11), x86_64, glibc 2.41, libstdc++/libgcc from gcc-14 (14.2.0), systemd 257. Launcher 3.39.31, native launcher 2.6.2, CEF 127.3.5+chromium-127.0.6533.120. Official launcher from http://minecraft.net . Present on every session since installation. Same six liblauncher.so offsets as above (0x1360a3 -> 0x29f2f1 -> 0x29f43d -> 0x29e9c2 -> 0x1e0b06 -> RunLauncher + 0x1b270e), same uncaught std::bad_function_call reported by the terminate handler in the journal. This rules out an Arch-specific cause or a newer-toolchain regression. New: patch.mojom.FilePatcher also aborts. On 2026-09-13 the launcher log shows 8 utility spawns in alternating pairs, matching 8 core dumps 1:1 (UTC): 15:23:42.469 patch.mojom.FilePatcher 15:23:42.490 unzip.mojom.Unzipper 15:23:42.578 patch.mojom.FilePatcher 15:23:42.600 unzip.mojom.Unzipper 15:23:42.689 patch.mojom.FilePatcher 15:23:42.737 unzip.mojom.Unzipper 15:23:42.963 patch.mojom.FilePatcher 15:23:43.007 unzip.mojom.Unzipper That makes three on-demand utility services failing (Unzipper, DataDecoder, FilePatcher) while the startup services are fine, consistent with the conclusion above that the factories for on-demand services are not registered in the child. The FilePatcher -> Unzipper pairing, together with the component_crx_cache / PKIMetadata / SafetyTips mtimes reported by Kryvoff, suggests the trigger is Chromium's component updater applying differential CRX updates in the background. That would explain why spawns appear unrelated to user actions or game launches. Duplicate report: MC-312512.
Can you confirm this on the latest version of Minecraft (26.3 Pre-release 1)?