Closed AngryPhantom closed 11 months ago
ilya-fedin
commented
11 months ago Are you sure it's due to kernel? Telegram uses CPU for rendering (it's based on QtWidgets, only media viewer has GL code) and there are lots of animating parts appeared during times, especially if you have emoji/sticker selector opened all the time (#25952).
AngryPhantom
commented
11 months ago @ilya-fedin Well, I'm sure because the software base is the same on both installations. It's a rolling distro, both HDDs are identical. The only difference is the kernel version. I also don't use emoji selector and it's never opened.
ilya-fedin
commented
11 months ago I mean the older installation likely has an older tdesktop that doesn't have those animations supported. Those animations aren't only in the emoji selector, they could be in chats and even in chat list. You can disable various animations in battery saving options and see whether it helps.
AngryPhantom
commented
11 months ago @ilya-fedin I check and update Telegram manually via Settings on both installations (not from repositories).
AngryPhantom
commented
11 months ago @ilya-fedin It's up-to-date on both installations. I've tried the previous version too (4.9.9) but it's the same.
ilya-fedin
commented
11 months ago Ah, indeed. I'm highly doubt it's due to kernel though (and then it's undebuggable, at least there's no one here who have respective experience), can you try disable animations in battery saving? So far all reports about CPU usage were due to animations even if reporters were saying they're sure it's not.
AngryPhantom
commented
11 months ago @ilya-fedin Everything is disabled since I don't like animations and stuff like that.
AngryPhantom
commented
11 months ago @ilya-fedin
I'm highly doubt it's due to kernel
Well, I just don't know what else to blame actually. I'm lost.
AngryPhantom
commented
11 months ago @ilya-fedin It happened before (high CPU usage), but it was long ago already. It either tried to download all history or something, thus giving CPU a bad time.
AngryPhantom
commented
11 months ago @ilya-fedin Oh! I waited for a minute or two and the CPU is now normal. So, we have something already. The CPU is high for a couple of minutes (like it was several versions ago) and comes back to normal.
ilya-fedin
commented
11 months ago Does 100% CPU usage goes for a long time? If yes, you can send SIGABRT to the process and it would generate a crash dump where it's possible to see what it does at each thread at the moment. Don't forget to enable beta for the crash reporter and copy crash ID before sending the crash report.
AngryPhantom
commented
11 months ago @ilya-fedin Well, I closed Telegram and opened again. It's normal now. It really tried to download something from the history I guess, but couldn't. If I closed it midway it gave high CPU usage again after starting it for a second or third time. But now, after letting it "do something" in the background, it's now normal on new restarts. Strange.
AngryPhantom
commented
11 months ago So, I guess, it was a profile issue. I also cleaned my temporary storage via Advanced settings. This happens from time to time with other programs like Firefox etc. I'm not sure who's fault this is. I'll close the issue.
AngryPhantom
commented
11 months ago @ilya-fedin Though it works I see a lot of segfaults in dmesg when closing Telegram, like this:
[ 129.071319] Telegram[1404]: segfault at 0 ip 0000000000000000 sp 00007fd17667c3f8 error 14 in Telegram[55aa0bf36000+b46000] likely on CPU 1 (core 1, socket 0)
[ 413.266960] Telegram[2276]: segfault at 0 ip 0000000000000000 sp 00007f57be70e3f8 error 14 in Telegram[55a9b762f000+b46000] likely on CPU 1 (core 1, socket 0)
[ 437.836836] Telegram[2450]: segfault at 0 ip 0000000000000000 sp 00007f4c4b9fd3f8 error 14 in Telegram[55e63a1c1000+b46000] likely on CPU 0 (core 0, socket 0)
[ 458.272115] Telegram[2504]: segfault at 18 ip 00007f4e8a092e06 sp 00007f4e80b9e4e0 error 4 in libc.so.6[7f4e8a026000+15f000] likely on CPU 0 (core 0, socket 0)
[ 467.346741] Telegram[2564]: segfault at 0 ip 0000000000000000 sp 00007f12192603f8 error 14 in Telegram[55681c2ca000+b46000] likely on CPU 1 (core 1, socket 0)
[ 1329.188460] Telegram[3959]: segfault at 0 ip 0000000000000000 sp 00007f0b8cffd3f8 error 14 in Telegram[55a3d08d7000+b46000] likely on CPU 1 (core 1, socket 0)Yeah, there's memory corruption somewhere on quit so it crashes randomly in allocator...
john-preston
commented
11 months ago @AngryPhantom Maybe it was initial emoji generation in the background? Theyre cached once ready.
Although two minutes is a bit much for that.
AngryPhantom
commented
11 months ago @ilya-fedin Sorry that was grep by 'Telegram' only. Here's more complete one:
[ 129.071319] Telegram[1404]: segfault at 0 ip 0000000000000000 sp 00007fd17667c3f8 error 14 in Telegram[55aa0bf36000+b46000] likely on CPU 1 (core 1, socket 0)
[ 129.071338] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 167.234987] EXT4-fs (sdb1): mounted filesystem ada71ba7-ebcc-4e65-a2f4-51c7e27607aa r/w with ordered data mode. Quota mode: none.
[ 194.541965] EXT4-fs (sdb1): unmounting filesystem ada71ba7-ebcc-4e65-a2f4-51c7e27607aa.
[ 413.266960] Telegram[2276]: segfault at 0 ip 0000000000000000 sp 00007f57be70e3f8 error 14 in Telegram[55a9b762f000+b46000] likely on CPU 1 (core 1, socket 0)
[ 413.266982] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 437.836836] Telegram[2450]: segfault at 0 ip 0000000000000000 sp 00007f4c4b9fd3f8 error 14 in Telegram[55e63a1c1000+b46000] likely on CPU 0 (core 0, socket 0)
[ 437.836858] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 458.272115] Telegram[2504]: segfault at 18 ip 00007f4e8a092e06 sp 00007f4e80b9e4e0 error 4 in libc.so.6[7f4e8a026000+15f000] likely on CPU 0 (core 0, socket 0)
[ 458.272138] Code: ff ff 83 c0 16 83 e0 f7 75 9c e9 5e ff ff ff 0f 1f 44 00 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 90 <8b> 57 18 64 8b 04 25 d0 02 00 00 39 c2 74 73 8b 07 89 c1 89 c2 83
[ 467.346741] Telegram[2564]: segfault at 0 ip 0000000000000000 sp 00007f12192603f8 error 14 in Telegram[55681c2ca000+b46000] likely on CPU 1 (core 1, socket 0)
[ 467.346765] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ 1329.188460] Telegram[3959]: segfault at 0 ip 0000000000000000 sp 00007f0b8cffd3f8 error 14 in Telegram[55a3d08d7000+b46000] likely on CPU 1 (core 1, socket 0)
[ 1329.188480] Code: Unable to access opcode bytes at 0xffffffffffffffd6.@john-preston It could have been one minute, it just seemed really long. Probably you're right about emoji caches or something. Anyway, it seems okay now.
ilya-fedin
commented
11 months ago Sorry that was grep by 'Telegram' only. Here's more complete one:
These logs with codes tell nothing to me
ilya-fedin
commented
11 months ago It could have been one minute, it just seemed really long.
I guess he meant it should be multiple seconds
AngryPhantom
commented
11 months ago I guess he meant it should be multiple seconds
Well, it didn't load CPU on another installation at all.
john-preston
commented
11 months ago Ok, you can try to clear the "/home/satellite/.local/share/TelegramDesktop/tdata/emoji" folder (it should have multiple "cache_XX_Y" files) and then launch the app again and see if it again burns the CPU while filling up this cache and then stops doing that when it is filled again.
But on my laptop even on a big interface scale i takes around 3 seconds to build up the cache. Taking one thread only, so having less than 10% of CPU usage.
AngryPhantom
commented
11 months ago @john-preston Yeah, that's it! Emoji cache is the culprit for some reason. After cleaning, it took a minute and 15 seconds to rebuild the cache, loading the CPU at 100%.
john-preston
commented
11 months ago wow, that's harsh.. I'm surprised it works more or less ok otherwise, given the difference in this emoji caching performance for my case and yours
All it's doing is opens huge webp image (that has thousands of 72x72 emoji images) and scales smoothly them one by one to required size, writing back much-less-but-still-huge images with full emoji atlases to the disk as cached copies.
This is how they work, I'm not sure this is going to be somehow changed anytime soon.
AngryPhantom
commented
11 months ago @john-preston Thank you very much for the info. Anyway, I'm glad it works fine after rebuilding the cache.
ilya-fedin
commented
11 months ago I'm surprised it works more or less ok otherwise, given the difference in this emoji caching performance for my case and yours
Maybe it's due to HDD rather than SSD?
AngryPhantom
commented
11 months ago @ilya-fedin You'll be surprised but I'm the one who haven't used SSD yet :) I have a pretty old machine: 4 GB RAM, AMD Athlon II X2 245 CPU and several HDDs. So it's definitely a Telegram issue, somewhere in the code. This happened to me before once or twice, don't remember exactly, it was really long ago, on versions 3.8.x or 3.9.x, not sure. Again, this didn't happen on another installation this time. Strange indeed. Well, it rebuilt the cache and it doesn't occur anymore now, so I'm happy with it. I just don't want to make a long discussion here (since the issue is closed already) and take your time, guys. Thank you very much for help and info! Cheers!
ilya-fedin
commented
11 months ago You closed the issue on your own, so GitHub should let you to reopen it. And then you can give the issue a better naming given that it's not related to kernel after all.
AngryPhantom
commented
11 months ago @ilya-fedin Yes, I know. I closed the issue because it resolved itself somehow. Let's just chalk it up to some random bug and that's all. If it occurs again or persists in the nearest future I'll investigate it more thoroughly and create a more relevant issue name.
john-preston
commented
11 months ago Well, then it's just the amount of computation it takes to cache the emoji.
This is expected to happen once each time I update the supported emoji internal, it happens once every new Unicode standard is released and all four emoji sets that are used in TDesktop are updated to that standard. They add some new emoji and the cache is rebuilt when a new version is installed. So this will happen later from time to time, approximately once a year or so.
AngryPhantom
commented
11 months ago approximately once a year or so
@john-preston Oh, didn't know that. Then the puzzle is solved! Thank you very much again.
Steps to reproduce
I'm experiencing a very high CPU usage on Arch Linux. I'm not sure if it's connected with newer kernels (6.5.2 currently) but it's like constantly 100% of any of my two CPU cores. Yesterday I did a fresh install of Arch on another HDD (a clean and fresh system, to test newer kernels etc.). I didn't even expect there could be such an issue. I also have an older installation with an LTS 5.15 kernel on another HDD, and there is no problem. The CPU is idle.
P.S. I have conky on my desktop so I instantly notice odd system behavior. You can also start htop and then Telegram and see it yourself.
P.P.S. I have disabled Hardware acceleration and OpenGL rendering in the Settings. But it doesn't fix the issue if I enable them.
Am I the only one with this issue?
TIA
SOLVED and CLOSED (see below).
Expected behaviour
Normal CPU usage
Actual behaviour
100% CPU usage
Operating system
Arch Linux
Version of Telegram Desktop
(4.9.9 or 4.10.0)
Installation source
Static binary from official website
Crash ID
No response
Logs
SOLVED: This can be an expected behavior when a new emoji set cache is being updated.