qTox insane CPU & RAM usage due to starting new processes from clicking on tox: links #1926
Comments
|
Did you intentionally open 6 different qTox instances? |
|
Nope. I just had it running for... about 7 to 9 days. I don't shut down my PC at all in general. Can't imagine it being on my side, unless these instances were started in issue 1925 while I was testing, and didn't shut down. Which I really doubt. |
|
Alright, I'll take a look at it, thanks. Can you post the log (in folder %APPDATA%/tox/qtox.log), please? |
|
@PhilHypnox Did you use video calls in these 7 to 9 days? If yes, did some of your contacts use utox? |
|
Reason - qTox cannot handle clicking on |
|
the log. And yes, it does appear to be the case. It only goes back to normal once all instances of qTox are closed. |
|
Thanks, I have a good idea of what the problem is now. Although a big part of the log is qTox not being able to connect to the network, is that a problem you had with qTox, or just spotty internet? |
|
Spotty connection, yes. |
|
Add tag l-slow. |
zetok
changed the title
zetok
changed the title
|
From #2271, it would appear that |
|
and new users can't use this link because link "tox:...." was registered by nsis setup |
|
More logs and steps to reproduce: #3167 |
|
on 1.8.1 bug is still present, although it results in 100% CPU usage only until one loads a profile |
Fixes #1926 : When an IPC event was processed locally, if the window was closed before the core could start, the event handler would be forever stuck in the background waiting for the core to start. We fix this by substituting QApplication::quit() by a Nexus::quit() function and a Nexus::isRunning() function, which gives us a condition for exiting blocking processEvents() loops. We cannot simply use QApplication::quit(), because this function has no effect before the start of the event loop. The problem was further exacerbated by the Tox URI event handler being (incorrectly) blocking. The IPC owner would block in this event handler, and the sender of the event would give up waiting and process the event itself a second time, potentially triggering the first bug. We fix the event handlers accordingly to be (mostly) non-blocking. Also fixes a related deadlock between ~Core and ~Profile in the case of an early exit
Fixes #1926 : When an IPC event was processed locally, if the window was closed before the core could start, the event handler would be forever stuck in the background waiting for the core to start. We fix this by substituting QApplication::quit() by a Nexus::quit() function and a Nexus::isRunning() function, which gives us a condition for exiting blocking processEvents() loops. We cannot simply use QApplication::quit(), because this function has no effect before the start of the event loop. The problem was further exacerbated by the Tox URI event handler being (incorrectly) blocking. The IPC owner would block in this event handler, and the sender of the event would give up waiting and process the event itself a second time, potentially triggering the first bug. We fix the event handlers accordingly to be (mostly) non-blocking. Also fixes a related deadlock between ~Core and ~Profile in the case of an early exit
Fixes #1926 : When an IPC event was processed locally, if the window was closed before the core could start, the event handler would be forever stuck in the background waiting for the core to start. We fix this by substituting QApplication::quit() by a Nexus::quit() function and a Nexus::isRunning() function, which gives us a condition for exiting blocking processEvents() loops. We cannot simply use QApplication::quit(), because this function has no effect before the start of the event loop. The problem was further exacerbated by the Tox URI event handler being (incorrectly) blocking. The IPC owner would block in this event handler, and the sender of the event would give up waiting and process the event itself a second time, potentially triggering the first bug. We fix the event handlers accordingly to be (mostly) non-blocking. Also fixes a related deadlock between ~Core and ~Profile in the case of an early exit
Running qTox, I noticed a significant slow-down in everything CPU-intensive that I do (playing movies suddenly became impossible in even 720p). This is the task manager screenshot:
Why is qTox eating up that much RAM & CPU?
I'm W7 x64.
The text was updated successfully, but these errors were encountered: