search

mumble-voip / mumble

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

Clicking the voice activity tray icon causes mumble to use 100% cpu #3977

Open RagingFlames opened 4 years ago

RagingFlames commented 4 years ago

Clicking the mumble tray icon ((The dude that is green when you aren't talking and blue when you are) causes mumble to completely saturate my CPU time. It also seems to be doing something weird with my mouse causing it to flicker and change what my active window is, but that may or may not be related. This only effects me when I am running Linux, although I'm not sure if it has to be Debian testing or not (That's what I'm running)

Steps to Reproduce Steps to reproduce the behavior:

  1. Open mumble
  2. Connect to any server
  3. Minimize mumble so the window goes away
  4. Find and click on the tray icon for mumble
  5. CPU should now be maxed out until you kill mumble

Expected behavior I expect the mumble window to reopen like it normally does and not max out my CPU

Screenshots https://postimg.cc/gallery/czik4756/

Desktop (please complete the following information): -Laptop Debian Bullseye -Kernel Version 5.4.0-4 -KDE version 5.17.5 -Mumble version (1.3.0+dfsg-1+b1)

Additional context Hovering over the the tray icon causes it sometimes not happen so make sure to just click it. You'll notice in the screenshot that Plasma is also having a hard time after this bug happens which might explain the plasma related problems I have after doing this. I can go more into detail on stuff if you need me to, but I'm not sure what else you need. Despite what htop and KSysGuard say the CPU "feels" maxed out and the computer is basically unusable. Even killing the process is a bit challenging. I think the reason for what they are reporting might have something to do with hyperthreading?

RagingFlames commented 4 years ago

So I just spent some time testing this out more. For some reason I can only get the bug to consistently happen on one server.

Krzmbrzl commented 4 years ago

Is that server publicly available? If so could you please share the URL for connecting to that server so we can try and reproduce the problem? :)

Krzmbrzl commented 4 years ago

I just tested it on KDE Neon 5.18 (runngin Linux 5.3 Kernel and with KDE Plasma 5.18.2) and was not able to reproduce the error (on an arbitrary server)

From the screenshots I take it that Mumble does not re-open again if you click on the tray-icon. Is this the case?

RagingFlames commented 4 years ago

The server that I can make it consistently happen on is a private server, so if possible I would like to avoid sharing it. That being said I spoke to the admin and he doesn't mind sharing it with someone privately if it means squashing a bug. The admin did want me to mention that they are just using the the mumble server software off of the testing branch of Debian on the default repository, nothing special.

I've been trying to zero in on more details to help people reproduce the bug. I noticed that the bug will only (Or at least more consistently? I don't remember what I did in the past) happen if mumble is maximized prior to minimizing it. You asked if mumble does not re-open again. After the bug happens my screen usually completely freezes after a few seconds, mumble does not re-open after I click the tray icon, though I did notice that if I wait a few minutes it may open and close itself. To clarify, my display get frozen by the bug, but I do get new frames pushed to the monitor every now and then, and on these frames mumble may or may not be open, I have no idea what causes that.

I'm debating doing a full screen recording of the process on OBS (At the very least to prove I'm not making it up!) but I might have to settle for recording it on my phone since the bug uses basically all my CPU time.

Krzmbrzl commented 4 years ago

The server that I can make it consistently happen on is a private server, so if possible I would like to avoid sharing it.

Sure. Have you tried to re-use the configuration that is in use for that server to see if that's enough to also make this bug happen?

That being said I spoke to the admin and he doesn't mind sharing it with someone privately if it means squashing a bug.

I might come back to this. Let's try and see if we can figure it out without it first though :)

The admin did want me to mention that they are just using the the mumble server software off of the testing branch of Debian on the default repository, nothing special.

Would that be Murmur 1.3 already or is this still 1.2?

I'm debating doing a full screen recording of the process on OBS (At the very least to prove I'm not making it up!) but I might have to settle for recording it on my phone since the bug uses basically all my CPU time.

A short video might indeed be useful. I don't think you're making this up but that way we might be able to see some details we missed when texting. I think a recording with your phone is enough for this purpose :+1:

Krzmbrzl commented 4 years ago

Oh and one more thing: Did other users on that server experience the same problem or is it only you? Could you get another user of that server to replicate the steps that caused the bug for you? If so, what was the outcome of that?

RagingFlames commented 4 years ago

Sure. Have you tried to re-use the configuration that is in use for that server to see if that's enough to also make this bug happen?

I have not, I assume you mean just asking for a copy of the config files, setting up my own server and testing to see if I get the same results? If yes I can try that as soon as I get a chance to speak with the admin again.

Would that be Murmur 1.3 already or is this still 1.2?

Admin said they are running 1.3 when I asked earlier.

A short video might indeed be useful. I don't think you're making this up but that way we might be able to see some details we missed when texting. I think a recording with your phone is enough for this purpose +1

Working on this as we speak!

Oh and one more thing: Did other users on that server experience the same problem or is it only you? Could you get another user of that server to replicate the steps that caused the bug for you? If so, what was the outcome of that?

The only other person who is even running linux on the server would be me and the admin. I asked him to try and replicate the bug immediately but it did not happen for him. I will ask him to try again but specify that mumble must be maximized before he minimizes it.

RagingFlames commented 4 years ago

So despite the video name I am well aware that this could in fact be a KDE bug, but I'm not an expert by any means so I have no idea. https://www.youtube.com/watch?v=8vk4wTIqYtg That's the video of the bug. To clarify, I am not switching the active window, that is just happening on its own. The buttons flashing is also not me. I did have to click several dozen times for the button to actually work though. I know the video doesn't show a tonne so if you want to see me try specific things just ask!

RagingFlames commented 4 years ago

Another update, I starting trying to get the bug to happen on other servers and I can get it to happen on most after a few tries as long as mumble is maximized before hand. I didn't know I had to maximize it before so when I tried earlier on different servers it didn't work, sorry about that!

Krzmbrzl commented 4 years ago

I assume you mean just asking for a copy of the config files, setting up my own server and testing to see if I get the same results?

Exactly

I didn't know I had to maximize it before so when I tried earlier on different servers it didn't work, sorry about that!

No problem. Then I'll try again with this method as well :point_up:

Krzmbrzl commented 4 years ago

Alright now I can reproduce the error on my machine as well. That's very good 'cause it means that I will be able to investigate the issue further :+1:

I get this error showing up in the terminal when the error occurs:

<W>2020-02-28 19:14:18.212 internal error:  void QXcbWindow::setNetWmStateOnUnmappedWindow() called on mapped window
RagingFlames commented 4 years ago

That's great! I'm glad you were able to reproduce it. If there is anything else you need from me just message, I'll be paying attention to the thread. Looking forward to updates.

Krzmbrzl commented 4 years ago

I played around with it some more and found out that you don't even have to be connected to a server for this to happen. And what actually happens is an endless loop in which the functions MainWindow::showEvent and MainWindow::hideEvent are continuously called one after the other. Thus the flickering of the screen is actually the application being shown and hidden in an endless loop.

For a reason I don't understand it makes a difference when the window is maximized vs when it's not. However even though the system seems to work in the latter case, I still see a short flicker and my tests revealed that during showing the window it actually gets hidden again and shown again causing the flickering. However in the non-maximized case the loop ends there.

I think this whole thing is related to our implementation of the "minimize-to-tray"-feature...

@RagingFlames what Qt version do you have running on your machine? I have 5.14.1 - do you happen to run the same version? My guess is that we have built this feature around some Qt inconsistencies/bugs that have now been changed/fixed causing the old approach to this to fail miserably.

Krzmbrzl commented 4 years ago

Yet another finding: It appears that the following code in MainWindow::showRaiseWindow is responsible for starting the event-mess that can eventually lead to the described endless loop. https://github.com/mumble-voip/mumble/blob/ec51a41cfe7a348d08c40468bc49aca0dbd3e9d8/src/mumble/MainWindow.cpp#L3108-L3110

I assume this is because setWindowState fires hide/show-events on its own confusing the overall system to a point beyond recovery.

When I remove that code-fragment, the bug disappears and also the other strange event-triggers seem to disappear. As I don't even notice this part missing, I wonder what it is even there for. @davidebeatrici do you know more on this?

RagingFlames commented 4 years ago

It looks like I'm using Qt version 5.9.7. I just checked it using "qmake --version".

RagingFlames commented 4 years ago

Just a heads up, the server admin I spoke to who could not replicate this bug has version 5.12.5-5

Krzmbrzl commented 4 years ago

Did he try after having Mumble maximized?

RagingFlames commented 4 years ago

Yes. I went back to him after my discovery and had him try full screen and maximized. He said nothing happened.

Krzmbrzl commented 4 years ago

What OS has he been trying it on?

RagingFlames commented 4 years ago

Ah crap, sorry. I'm wrong. I'm using 5.12.5, same as the admin (accidentally looked in the wrong place). Me and him are using the same OS, Debian bullseye. Although I don't think that makes things better...

Krzmbrzl commented 4 years ago

Although I don't think that makes things better...

Indeed it does not xD However I think the most important part is that I can reproduce the bug on my machine :)

Krzmbrzl commented 4 years ago

@RagingFlames is the admin also using KDE?

Krzmbrzl commented 4 years ago

Linking some relevant stuff for me:

RagingFlames commented 4 years ago

The admin is also using KDE.

Krzmbrzl commented 4 years ago

Hm okay. We probably need some testing on different OSs and with different Desktop environments / window managers on Linux to see if this might be a general issue with Qt, a bug in KDE or in fact a problem of our implementation... :thinking:

muesli commented 4 years ago

The window being maximized seems to be the key trigger here. I couldn't reproduce this before I tried it with the window being maximized.

Krzmbrzl commented 4 years ago

@muesli what OS are you using?

muesli commented 4 years ago

Up-to-date ArchLinux with Plasma 5.18.5.

streaps commented 4 years ago

I'm not sure if I'm doing it correctly, but Mumble 1.3.0 has some funny behaviour on Raspbian (Debian) Buster with LXDE too.

Maximize window, click on tray mic -> window is hidden click on tray mic again -> 1) window shows un-maximized again (size before I maximized it) or 2) there is some flickering, but I see nothing. Clicking two times more on tray mic shows the un-maxmized window again.

Krzmbrzl commented 4 years ago

I think the hide-to-tray stuff is fundamentally broken and has all kinds of weird stuff happening. I think someone (maybe I) has to rewrite that part to make it work properly...

ghost commented 1 year ago

Is this just waiting on reproduction with https://github.com/mumble-voip/mumble/issues/1233 or something else?

Krzmbrzl commented 1 year ago

This is waiting for a complete rewrite of the minimize to tray handling as the current one is a bloody mess and causes all sorts of bugs ^^