mirror of
https://github.com/mumble-voip/mumble.git
synced 2026-03-03 00:46:56 -05:00
Segmentation fault on launch (1.6.0) #3102
Labels
No labels
GlobalShortcuts
Hacktoberfest
accessibility
acl
asio
audio
bonjour
bsd
bug
build
certificate
ci
client
code
documentation
external-bug
feature-request
gRPC
github
good first issue
help wanted
help-needed
ice
installer
linux
macOS
needs-ckeck-with-latest-version
needs-more-input
overlay
positional audio
priority/P0 - Blocker
priority/P1 - Critical
priority/P2 - Important
priority/P3 - Somewhat important
priority/P4 - Low
public-server-registration
qt
recording
release-management
server
stale-no-response
stale-support
support
task
test
theme
translation
triage
ui
windows
wontfix
x64
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mumble-mumble-voip#3102
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @billypom on GitHub (Feb 17, 2026).
Description
Mumble fails to launch - segmentation fault.
Steps to reproduce
mumbleMumble version
1.6.0
Mumble component
Client
OS
Linux
Reproducible?
Yes
Additional information
window_stateorwindow_geometryfrom~/.config/Mumble/Mumble/mumble_settings.jsonthen I can launch mumble again without issue. Closing and attempting to reopen reproduces the issue.Not sure if this is a Qt, Wayland, or Mumble issue. I have not experienced this issue with other Qt apps, so I figured I would submit a bug report to Mumble. Unsure of a way to enable more verbose logging. Just let me know if I can provide something more helpful.
Relevant log output
Screenshots
@Krzmbrzl commented on GitHub (Feb 18, 2026):
Did you self-compile Mumble? Or rather: do you think you would be capable of compiling a debug version of Mumble in order to reproduce the issue in a debugger (to get a full stacktrace)?
@Hartmnt commented on GitHub (Feb 18, 2026):
This is probably similar to #6577
But, as this happens in a loop, Qt and hyprland seem to be disagreeing on what a valid
window_statewould be. Not sure if we can really do anything about this.I mean we could simply not
restoreStateon Wayland...@billypom commented on GitHub (Feb 20, 2026):
I would be open to compiling a debug version if it would help you guys. Is there a debug-mode compilation guide somewhere on the github? Maybe using the
debugUSE flag would be sufficient (https://wiki.gentoo.org/wiki/Mumble). I will try recompiling with that flag tonight and see if the backtrace is any better.Yea this seemed hyprland specific -or maybe specific to a dynamic tiling window managers. "Traditional" wayland Desktops Envs may not have this issue since Qt can spawn the window at any position on top of other windows. I wouldn't suggest disabling
restoreStateon wayland altogether.I wonder if having the
Server>Connectwindow that opens on launch be modal/attached to the main window would resolve it (I'll poke around to see if thats already an option, or see if I can disable that window on startup).@Hartmnt commented on GitHub (Feb 20, 2026):
symbolsInteresting idea, it should™️ be the case that only the MainWindow state is saved. But, it could very well be the case that some other window, modal is the culprit. Maybe including a race-condition somehow usually not found on the classic compositors?
@billypom commented on GitHub (Feb 20, 2026):
I was able to build 1.6.0 on Gentoo from the git repo and reproduced the issue.
Turned off support for libs that would take too long to compile and not related to the issue
Output from the terminal
Doesn't look more helpful than the original stacktrace to me... Is there somewhere else I should be looking for more debug output?
@billypom commented on GitHub (Feb 20, 2026):
Something maybe noteworthy that I've reasoned out - I am only able to reproduce the issue under a specific circumstance. I have 2 monitors laid out like this:
BBAYou can swap
AandBin the explanation and the same issue occurs.Maybe
window_geometryandwindow_stateare not "synced" with each other? One gets updated on launch, one on close, and that causes some kind of freakout? Not really sure what to make of it... that's just my first thought.Here is the current state of those params in the config.
@Hartmnt commented on GitHub (Feb 20, 2026):
@billypom Could you run it through gdb?
gdb ./mumbleand thenrunin the interactive gdb session I think@billypom commented on GitHub (Feb 20, 2026):
@Hartmnt sure -
First run
mumble opens
move main window to another monitor
then close main window
2nd run