Please confirm the following.
What version of the Modrinth App are you using?
0.15.7
What operating systems are you seeing the problem on?
Linux
Describe the bug
Opening an instance's Content tab (or otherwise triggering linked-modpack content resolution) for a modpack with many mods causes the app to fire a burst of duplicate, near-simultaneous identical HTTP requests to the same URL. This appears to overload something in the embedded WebKitGTK web view (rendering many rapid state/DOM updates and/or exhausting the connection pool), and the app segfaults inside libwebkit2gtk-4.1.so shortly after.
Ran with RUST_LOG=debug to capture the launcher log around the crash. In the ~100ms window right before the crash, the log shows:
get_linked_modpack_content → get_team_many (resolving team info for ~40+ project IDs)
get_linked_modpack_info → get_organization → get_organization_many
Then 14 duplicate identical fetch_json GET https://launcher-meta.modrinth.com/forge/v0/manifest.json calls fired within about 100ms of each other (grep count on the log: 14 occurrences in this single window)
Shortly after, the process receives SIGSEGV. coredumpctl debug on the resulting core file shows the crashing thread entirely inside WebKitGTK/JavaScriptCoreGTK, called from the normal GTK/glib main loop — not from app-level Rust code:
#0 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#1 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#2 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#3 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#4 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#5 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#6 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#7 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#8 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#9 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#10 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#11 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#12 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#13 0x... in ?? () from .../libglib-2.0.so.0
#14 0x... in ?? () from .../libglib-2.0.so.0
#15 0x... in g_main_context_iteration () from .../libglib-2.0.so.0
#16 0x... in gtk_main_iteration_do () from .../libgtk-3.so.0
#17-23 (app's own PIE addresses, stripped release binary, no symbols)
#24 __libc_start_call_main
#25 __libc_start_main_impl
(Ubuntu's libwebkit2gtk-4.1-0 package ships without debug symbols, so the exact function names inside WebKitGTK aren't resolvable without dbgsym packages — happy to pull those and re-capture if useful.)
Separately, and possibly unrelated, at app startup the log also shows:
ERROR get_game_version_tags: theseus::state: Attempted to get state before it is initialized - this should never happen!
ERROR get_loader_tags: theseus::state: Attempted to get state before it is initialized - this should never happen!
This didn't appear to crash the app immediately, but may indicate a startup race condition worth looking at separately.
Steps to reproduce
Install/open a large modpack instance with many mods (repro'd with "Fabulously Optimized")
Open the instance's Content/mods list
Within a few seconds to ~1 minute, the app becomes laggy and then crashes (SIGSEGV)
Expected behavior
Requests for the same resource (e.g. forge/v0/manifest.json) should be deduplicated/cached rather than fired once per mod being resolved, and the renderer shouldn't crash even under request-storm conditions.
Additional context
Confirmed this is not a driver/GPU issue: the same crash reproduces after extracting the AppImage to a persistent path (so full backtraces are available) and with WEBKIT_DISABLE_DMABUF_RENDERER=1 set (which does fix a separate, more general WebKitGTK+NVIDIA rendering-lag issue on this machine, but does not prevent this specific segfault).
Happy to provide the full debug log or core dump if useful.
Please confirm the following.
What version of the Modrinth App are you using?
0.15.7
What operating systems are you seeing the problem on?
Linux
Describe the bug
Opening an instance's Content tab (or otherwise triggering linked-modpack content resolution) for a modpack with many mods causes the app to fire a burst of duplicate, near-simultaneous identical HTTP requests to the same URL. This appears to overload something in the embedded WebKitGTK web view (rendering many rapid state/DOM updates and/or exhausting the connection pool), and the app segfaults inside libwebkit2gtk-4.1.so shortly after.
Ran with RUST_LOG=debug to capture the launcher log around the crash. In the ~100ms window right before the crash, the log shows:
get_linked_modpack_content → get_team_many (resolving team info for ~40+ project IDs)
get_linked_modpack_info → get_organization → get_organization_many
Then 14 duplicate identical fetch_json GET https://launcher-meta.modrinth.com/forge/v0/manifest.json calls fired within about 100ms of each other (grep count on the log: 14 occurrences in this single window)
Shortly after, the process receives SIGSEGV. coredumpctl debug on the resulting core file shows the crashing thread entirely inside WebKitGTK/JavaScriptCoreGTK, called from the normal GTK/glib main loop — not from app-level Rust code:
#0 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#1 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#2 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#3 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#4 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#5 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#6 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#7 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#8 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#9 0x... in ?? () from .../libwebkit2gtk-4.1.so.0
#10 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#11 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#12 0x... in ?? () from .../libjavascriptcoregtk-4.1.so.0
#13 0x... in ?? () from .../libglib-2.0.so.0
#14 0x... in ?? () from .../libglib-2.0.so.0
#15 0x... in g_main_context_iteration () from .../libglib-2.0.so.0
#16 0x... in gtk_main_iteration_do () from .../libgtk-3.so.0
#17-23 (app's own PIE addresses, stripped release binary, no symbols)
#24 __libc_start_call_main
#25 __libc_start_main_impl
(Ubuntu's libwebkit2gtk-4.1-0 package ships without debug symbols, so the exact function names inside WebKitGTK aren't resolvable without dbgsym packages — happy to pull those and re-capture if useful.)
Separately, and possibly unrelated, at app startup the log also shows:
ERROR get_game_version_tags: theseus::state: Attempted to get state before it is initialized - this should never happen!
ERROR get_loader_tags: theseus::state: Attempted to get state before it is initialized - this should never happen!
This didn't appear to crash the app immediately, but may indicate a startup race condition worth looking at separately.
Steps to reproduce
Install/open a large modpack instance with many mods (repro'd with "Fabulously Optimized")
Open the instance's Content/mods list
Within a few seconds to ~1 minute, the app becomes laggy and then crashes (SIGSEGV)
Expected behavior
Requests for the same resource (e.g. forge/v0/manifest.json) should be deduplicated/cached rather than fired once per mod being resolved, and the renderer shouldn't crash even under request-storm conditions.
Additional context
Confirmed this is not a driver/GPU issue: the same crash reproduces after extracting the AppImage to a persistent path (so full backtraces are available) and with WEBKIT_DISABLE_DMABUF_RENDERER=1 set (which does fix a separate, more general WebKitGTK+NVIDIA rendering-lag issue on this machine, but does not prevent this specific segfault).
Happy to provide the full debug log or core dump if useful.