Closed Hi-Angel closed 4 months ago
This is weird, the issue template lost data. I was basically saying the problem is not reproducible on my newer laptop, but I have to use the older one for now and I immediately stumble upon this problem.
I wish people didn't use Github issue auto-template, because it frequently loses data.
I see only a short time spike in CPU consumption which looks expected to me. What is the issue?
I see only a short time spike in CPU consumption which looks expected to me. What is the issue?
Well, I'm not sure seeing such picture non-stop all the time while Telegram is running counts as a spike…
so I can't reproduce that
Yes, as I mentioned it's not reproducible on my newer laptop either, but I have to work on the older laptop now and it is a problem there.
Well, I can't do anything if I can't reproduce. Sorry.
Hi, I think that I have got the same issue and can reproduce it https://ibb.co/6HZ6RXj here is the error, that I receive every time, I try to launch it
@Satoshics by any chance, are you using a KDE Wayland? I've noticed that this issue is only reproducible under KDE Wayland, but not under KDE X11 or Gnome Wayland. So it's most likely a kwin's problem. I didn't report it to kwin though as I didn't have time.
Not exactly, I am using Wayland, but with hyprland
I see. Please test if it's reproducible on your system with another Wayland compositor (besides kwin of course), and if it isn't, I presume you might need to create a report to hyprland.
Just to be clear: it may be a bug in Telegram (which is why I'm not closing it), but given the fact Gnome Wayland has a way to avoid it, it may also be something that a compositor may trivially work around, e.g. in case there might be some other programs that misbehave same way.
Note that third party builds are affected by https://bugreports.qt.io/browse/QTBUG-120565 while official builds (not distro official builds which are third party for Telegram but the Telegram official builds from https://desktop.telegram.org) have patched Qt to avoid this bug. If anyone of you are using not an official build with patched Qt, you may experience this bug which has no other solution than switching to official build with patched Qt.
thanks ilya, you really helped, i think this issue related to AUR at least for me, as the official build works fine
FTR, the original issue is reported for the official build, it's also part of "steps-to-reproduce".
Well, it seems my feeling that people using third party builds are mixing their unrelated issues here was right
I was seeking multiple days for a similar issue reported a bit earlier and I think I found it - #27930. The reporter of that issue has disappeared, though. The uploaded debug logs have MTP Info: dcWithShift 2 stopped send timer, can wait for 0ms from current 0 (session.cpp : 25)
lines which might be related (sounds like reconnecting every 0ms although I may be wrong) so it's a good idea to check your logs for similar lines.
I have a feeling that this is somehow related to getting last user input time, there were reports that it slows down the application on Wayland but not on X11, the reports were primarily from GNOME Wayland users back then, though. It got solved by calling the API not that frequent but maybe this reconnecting thing or something else calls it too frequent again... Launching the application with DBUS_SESSION_BUS_ADDRESS=0
should show whether it's related to D-Bus requests (which getting last user input time is on Wayland while is a X11 request on X11, although it's far from being the only D-Bus request tdesktop does).
The only way to know for sure is likely to run tdesktop under a CPU profiler, though. Can you do that? Not sure whether that would show anything useful with the binary though, you might need to build tdesktop from source with debug symbols.
Well… that's an anticlimactic ending… It just stopped reproducing 👀 I swear I changed nothing at all: I did not update the system since then, nor I re-download Telegram from the site, it's the same binary the bug was reported against. Environment is completely the same. No idea what happened.
It was reproducible with both official and non-official binaries — but now it happens with neither. Logging in also does not make it appear (tested with both binaries).
The uploaded debug logs have
MTP Info: dcWithShift 2 stopped send timer, can wait for 0ms from current 0 (session.cpp : 25)
lines which might be related (sounds like reconnecting every 0ms although I may be wrong) so it's a good idea to check your logs for similar lines.
Well, at least I can reply on that part: these lines should appear in the same log file that I have pasted on this issue, and I can see here that the word MTP
is not mentioned there. Also note that the problem was happening to me without even logging in, so there may not even be anything to connect to at that stage. The logs in the report were taken from "non-logged in Telegram with 100% CPU load".
these lines should appear in the same log file that I have pasted on this issue,
No, those lines are written only to the logs in the DebugLogs folder, not to the log.txt.
so there may not even be anything to connect to at that stage
tdesktop connects right from the first launch I believe
these lines should appear in the same log file that I have pasted on this issue,
No, those lines are written only to the logs in the DebugLogs folder, not to the log.txt.
Oh, so there's more than one log, I see. The reason I concluded that was because I found the "MTP" line on the linked issue, and as the user didn't mention what file did they get it from, I just looked at the beginning of the log and compared to mine. First lines match, so I thought it is the same file. Sorry for confusion.
Steps to reproduce
Expected behaviour
It shouldn't take any noticeable CPU
Actual behaviour
It takes 100% of CPU
Operating system
Archlinux
Version of Telegram Desktop
5.1.4
Installation source
Static binary from official website
Crash ID
No response
Logs