search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.33k stars 1.11k forks source link

1.4.230 UI hangs/unresponsive #5631

Open Cyruz143 opened 2 years ago

Cyruz143 commented 2 years ago

Description

Been running through this with @Krzmbrzl but we're pretty much out of ideas (initially).

Originally had 1.3.4 installed. Managed to miss the warning about upgrading. When it failed to load properly with an error about migrating shortcuts. Uninstalled 1.3.4 fully, nuked the reg keys (Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble) and the AppData folder.

Running 1.4.230 gives me visible title bars but no UI, it just hangs there, no load (CPU/RAM) noted in task manager.

Manually set Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble\Mumble\lastupdate to 2 to bypass the audio wizard pop up. Still hung on Consent form. Manually set Computer\HKEY_CURRENT_USER\SOFTWARE\Mumble\Mumble\consent\pingserversdialogviewed to true to bypass the consent pop up. Still hangs on load.

Re-installed 1.3.4, all works fine. Tried the mumble_client-1.5.183-x64 snapshot, same issue as 1.4.230.

Steps to reproduce

1, Open Mumble

  1. App hangs

Mumble version

1.4.230

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

<W>2022-04-21 10:45:54.633 G15LCDEngine_lglcd: Logitech LCD Manager not detected.
<D>2022-04-21 10:45:54.634 libopus 1.3.1-97-g6b6035ae from C:/Program Files/Mumble/client/opus.dll
<W>2022-04-21 10:45:54.637 CELT bitstream 8000000b from C:/Program Files/Mumble/client/celt0.0.7.0.dll
<W>2022-04-21 10:45:54.639 Theme: "Mumble"
<W>2022-04-21 10:45:54.639 Style: "Lite"
<W>2022-04-21 10:45:54.639 --> qss: ":themes/Mumble/Lite.qss"
<W>2022-04-21 10:45:54.640 Locale is "en_GB" (System: "en_GB")
<W>2022-04-21 10:45:54.770 Database SQLite: "3.35.5"
<W>2022-04-21 10:45:54.793 Updating application palette
<W>2022-04-21 10:45:54.800 XboxInput: using XInput DLL 'XInput1_4.dll'
<W>2022-04-21 10:45:54.800 XboxInput: using XInputGetStateEx() as querying function.
<W>2022-04-21 10:45:54.902 QMetaObject::connectSlotsByName: No matching signal for on_qtvUsers_customContextMenuRequested(QPoint,bool)
<W>2022-04-21 10:45:55.052 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.052 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.055 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.057 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.074 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.075 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.230 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 0 channel 48000 hz echo
<W>2022-04-21 10:45:55.259 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.259 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.259 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.259 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.260 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.266 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.266 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.268 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.268 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.280 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.280 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.462 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.462 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.463 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.463 WASAPIInput: Echo Stream format 1
<W>2022-04-21 10:45:55.463 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-04-21 10:45:55.479 AudioInput: Opus encoder set for high quality speech
<W>2022-04-21 10:45:55.479 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2022-04-21 10:45:55.481 WASAPIOutput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.481 WASAPIInput: Latencies 100000 30000 => 100000
<W>2022-04-21 10:45:55.492 WASAPIInput: Mic Stream format 1
<W>2022-04-21 10:45:55.492 WASAPIInput: Stream Latency 0 (1056)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Output stream format 1
<W>2022-04-21 10:45:55.680 WASAPIOutput: Stream Latency 0 (2880)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Periods 10000us 3000us (latency 0us)
<W>2022-04-21 10:45:55.680 WASAPIOutput: Buffer is 60000us (5)
<W>2022-04-21 10:45:55.681 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-04-21 10:45:55.681 WASAPIInput: Echo Stream format 1
<W>2022-04-21 10:45:55.681 AudioInput: Initialized mixer for 2 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-04-21 10:45:55.690 AudioInput: Using RNNoise as noise canceller
<W>2022-04-21 10:45:55.690 AudioInput: ECHO CANCELLER ACTIVE

Screenshots

image

davidebeatrici commented 2 years ago

Could you perhaps run Mumble through a debugger? That way we know where the GUI thread gets stuck.

Cyruz143 commented 2 years ago

Could you perhaps run Mumble through a debugger? That way we know where the GUI thread gets stuck.

Not a developer by trade, can you give specific steps to follow?

Edit: Found instructions on the wiki, attaching log. debug.txt

davidebeatrici commented 2 years ago

The file you sent me actually contains the output of the console.

You can use WinDbg to get a backtrace.

Cyruz143 commented 2 years ago

That file is from WinDbg. I just followed the steps on the wiki.

davidebeatrici commented 2 years ago

Sorry, you're right. Did you load the debug symbols before obtaining the backtrace?

Cyruz143 commented 2 years ago

Looks like I didn't, I've added a newer trace here. debug_symbols.txt

It looks like the debugger also hangs when it's trying to dump the callstack, I left it sat there for 5 minutes, F5'd and then tried another breakpoint. Wouldn't log any further than the last line regarding QEventDispatcherWin32

davidebeatrici commented 2 years ago

Thanks, I'm fairly sure that's indeed the issue:

<X>2022-04-22 19:35:00.376 QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)(263c.39ac): Break instruction exception - code 80000003 (first chance)

How many handles and threads exist according to Windows' task manager when Mumble freezes?

Cyruz143 commented 2 years ago

537 Handles and 14 Threads. Really weirdly, open task manager will cause mumble to unfreeze a bit (system interrupt?). Enough that I can see the server list but it's still frozen after that and I cannot close it etc.

davidebeatrici commented 2 years ago

537 handles and 14 threads for the entire operating system?

Here's the task manager on my VM for comparison:

Cyruz143 commented 2 years ago

That was just the handles and threads for Mumble itself. Do you want system wide?

davidebeatrici commented 2 years ago

Yes, thanks.

Cyruz143 commented 2 years ago

image

davidebeatrici commented 2 years ago

Looks perfectly fine to me, I'm pretty sure you're encountering https://bugreports.qt.io/browse/QTBUG-94570.

I'll rebuild the vcpkg environment as soon as possible so that new builds will use a version of Qt that should theoretically have a fix for the bug.

Cyruz143 commented 2 years ago

Nice, if you can compile a quick Windows build when you have a chance, I'd be happy to test it to ensure it's resolved.

Krzmbrzl commented 2 years ago

Update on this: We found that the issue should be fixed in Qt 5.15.4, but apparently this release is only available to folks subscribing to the extended support releases. For us mere mortals, the last available release is 5.15.2. Therefore, we will unfortunately not be able to fix the issue you are encountering until Qt decides to publish a version containing this fix and make it available to the general public.

Since this issue is no longer actionable for us, I'll close this issue as out of our control.

EDIT: References:

davidebeatrici commented 2 years ago

microsoft/vcpkg#24660

@Cyruz143 We updated the build environment with Qt 5.15.4; could you check whether the issue persists with the latest artifact from CI, please?

Krzmbrzl commented 2 years ago

(Which is available from https://dev.azure.com/Mumble-VoIP/Mumble/_build/results?buildId=6054&view=artifacts&pathAsName=false&type=publishedArtifacts)

Cyruz143 commented 2 years ago

Still exhibits the same issue sadly. Will try and get more debugging data when I have the time.

Krzmbrzl commented 2 years ago

In that case, this doesn't seem to be the Qt bug after all :thinking: :eyes:

davidebeatrici commented 2 years ago

Unless the bug is in multiple places...

Krzmbrzl commented 2 years ago

@Cyruz143 do you have any peripherals other than keyboard and mouse connected to your computer? If so, could you try unplugging them and then check whether the issue persists?

See also https://forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals/

Cyruz143 commented 2 years ago

I just tried it with 1.4.274 and it works fine now... Flight pedals plugged in still, all seems to work fine now. Something fixed in between current stable and 1.4.230 perhaps?

Krzmbrzl commented 2 years ago

Lol xD

Something fixed in between current stable and 1.4.230 perhaps?

Not intentionally, but we take what we get ^^

mikeev261 commented 1 year ago

I'm on 1.4.287 and I'm currently getting this exact issue. At first I was able to get it to go away by unplugging some USB sound cards I had (that worked fine with other apps), but now even with them disconnected I get a hard freeze of the Mumble UI as soon as it starts up.

This is the tail of my log: 

<W>2022-10-23 19:45:17.846 WASAPIOutput: Periods 10000us 2666us (latency 0us)
<W>2022-10-23 19:45:17.846 WASAPIOutput: Buffer is 60000us (5)
<W>2022-10-23 19:45:17.846 AudioOutput: Initialized 2 channel 48000 hz mixer
<W>2022-10-23 19:45:17.849 WASAPIInput: Mic Stream format 1
<W>2022-10-23 19:45:17.849 WASAPIInput: Stream Latency 0 (1056)
<W>2022-10-23 19:45:17.860 WASAPIInput: Echo Stream format 1
<W>2022-10-23 19:45:17.860 AudioInput: Initialized mixer for 1 channel 48000 hz mic and 2 channel 48000 hz echo
<W>2022-10-23 19:45:17.888 AudioInput: Using Speex as noise canceller
<W>2022-10-23 19:45:17.888 AudioInput: ECHO CANCELLER ACTIVE
<X>2022-10-23 19:46:16.817 QEventDispatcherWin32::registerTimer: Failed to create a timer (The current process has used all of its system allowance of handles for Window Manager objects.)

Note the same "Failed to create a timer" message at the end.

Any ideas?

davidebeatrici commented 1 year ago

Could you run rawinput.exe from Joystick-Input-Examples_e2f196877de59134ac1499351d8e7391f4c6a3e0.zip and send here a screenshot of the window, please?

mikeev261 commented 1 year ago

Could you run rawinput.exe from Joystick-Input-Examples_e2f196877de59134ac1499351d8e7391f4c6a3e0.zip and send here a screenshot of the window, please?

It's just running endlessly...

image

mikeev261 commented 1 year ago

Just to add, similar to the thread linked above (https://forums.mumble.info/topic/14467-14-conflict-with-flight-control-rudder-pedals/) I also have multiple analog HID peripherals connected. I disconnected them all and Mumble works fine again... so they definitely seem related to this problem.

I tried moving them around to different USB controllers in my system, including a couple on my motherboard and 1 dedicated PCI-E USB 3.0 card. None of these mitigations helped.

davidebeatrici commented 1 year ago

Excellent, thank you very much for your report!

It's now pretty much confirmed the issue is related to global shortcuts and can be encountered when at least one device is sending a lot of packets/messages.

The proper solution would consist in using our own queue instead of Qt's event one.

mikeev261 commented 1 year ago

Sure thing! So does that mean that we'll eventually see this fixed in a future release? Should I fall back to 1.3.x in the meantime (from what I understand, this appeared in 1.4)?

davidebeatrici commented 1 year ago

The answer is affirmative to both questions.

mikeev261 commented 1 year ago

Hi, I just tried v1.5.517 (1.5.x RC) and the issue still seems to be present. Should this fix be merged into that branch?

Krzmbrzl commented 1 year ago

It is present in that branch, but apparently it doesn't quite work. See also #6054

StrangePeanut commented 5 months ago

My Mumble (Windows client 1.4.287) recently started freezing on launch. I was testing a PC monitor at the time which was the only thing out of the ordinary. The monitor supported audio over DisplayPort (NVIDIA High Definition Audio). The NVIDIA drivers were up to date. I could replicate the issue every time. Upon disconnecting the monitor, the freezing stopped immediately. I remember seeing this issue a while back and thought that this info might be helpful in one way or another.

Overdrivendev commented 3 weeks ago

Hello, this issue still seems to be present in v1.5.634. On connecting my device (a VRS DirectForce Pro wheel base) the mumble client will lock up and consume upto 25% of cpu time. I previously did work on 1.4.xxx builds with an older firmware on the wheelbase but after a Windows reinstall and grabbing the latest versions of all related software/firmware the issue happens. For now I've downgraded Mumble to 1.3.4 as the device handling works fine in this version with the latest firmware on the wheelbase.