Tdesktop: huge memory leak in work with cached images and medium leak with loading images

[MBkkt]

https://github.com/telegramdesktop/tdesktop/issues/1317
Why closed?
I tried 1.9.19, if you watch the channel with pictures, the memory leaks in the same way. If you watch the channel only with gifs, there are no memory leaks.
The fix referring to which you closed the bug only works for history/view/media/history_view_gif.h

[john-preston]

@MBkkt Can you please provide an example of a public channel with such problem and information about the memory consumption after you scroll through enough of images.

[lejabque]

@john-preston Well, I checked it in a channel https://t.me/lentachold and memory increased 10 times when i scrolled. Then I closed and left the channel but client still using 1.2gb.
Version 1.9.19, Kubuntu 19.10

[john-preston]

@lejabque I'm not sure this is the case described in the original issue, between posts that you show there are more than 15'000 messages. Currently Telegram Desktop stores all messages in memory (while caching the images and animations on HDD), so it does take a lot of memory in this case -- but I'm sure if you scroll some channel with 15'000 GIF animations it won't be much better. Or it could be much worse.

[lejabque]

@john-preston but there is no problem while I'm scrolling channel with gifs, e.g. t.me/cgifs

Also is it ok that ram not freed a few hours after scrolling?

[john-preston]

@lejabque Do the GIFs autoplay?

[john-preston]

@lejabque Messages (text and media metadata) are not freed unless messages are deleted. But they should not take lots of memory.

Also, /cgifs has 3'000 messages, so even if you scroll up till the very beginning of that channel, it will be less than 20% of messages that you've loaded in /lentachold - about additional 200 MB compared to additional 1 GB in /lentachold, for example.

[john-preston]

Tried to memory-profile a long-lentachold-scroll :/ I'll try some other time.

[ab123321]

between posts that you show there are more than 15'000 messages. Currently Telegram Desktop stores all messages in memory (while caching the images and animations on HDD), so it does take a lot of memory in this case -- but I'm sure if you scroll some channel with 15'000 GIF animations it won't be much better. Or it could be much worse.

@john-preston This way or another, it's not a rare occasion that tgdesktop takes more than 1 GB after several days of uptime (laptops are affected harder due to small capacity of RAM). If you have a lot of chats and groups, even light usage of client would cause abovementioned problem, without having to reproduce it on purpose.
With no doubt memory usage after December patch became much better, but large amount of RAM still being wasted even when you have client window closed does not sound like a proper or expected behaviour.

[Hezkore]

I'm not sure this is relevant to what's going on here.
But I've noticed that Telegram uses a whole lot more memory these days.
It used to stay just below Steam at around 130 MB, but I now typically see it around 300 MB.
Well above Steam, and even Discord.

[Khomyak-sibiryak]

https://github.com/telegramdesktop/tdesktop/issues/7280 I have a similar problem with RAM consumption. How to tell the client that after leaving the chat, channel, player, he must free up RAM?

[MBkkt]

@Khomyak-sibiryak
This cannot be done:(
I think if the application can consume an unlimited amount of memory, this is a leak.
@john-preston doesn't seem to think so, and therefore people who have a lot of chats have to suffer and restart telegram manually at least once a day.

[jeffythedragonslayer]

@lejabque
Can you post output of running it under valgrind?

[john-preston]

@MBkkt It should work differently, I hope to fix that some day. But it is a huge amount of work, it's not just "find a bug that leaks memory and fix it", because it is working mostly as intended.

I was hoping that apart from working as intended (and holding all the messages you saw in memory) it also has some bug that leaks much more memory than the messages texts and media metadata. But for now I didn't find one.

[Ezri]

@Khomyak-sibiryak
This cannot be done:(
I think if the application can consume an unlimited amount of memory, this is a leak.
@john-preston doesn't seem to think so, and therefore people who have a lot of chats have to suffer and restart telegram manually at least once a day.

Simple workaround would be add a reload button, similar to the one when you need to run an update. Would not solve the underlying problem, but makes it easier to handle.

[jeffythedragonslayer]

I do not see how a reload button would make sense. If memory is leaking then the application is either letting pointers go out of scope without free()ing or deleting them, or is holding on to lots of old pointers and then also not free()ing or deleting them. By the time someone figures out which is happening it should be pretty straightforward to insert the missing calls to free() or delete into the source.

[Ezri]

I do not see how a reload button would make sense. If memory is leaking then the application is either letting pointers go out of scope without free()ing or deleting them, or is holding on to lots of old pointers and then also not free()ing or deleting them. By the time someone figures out which is happening it should be pretty straightforward to insert the missing calls to free() or delete into the source.

The visible problem I am associating with this issue is that image previews of new images stop loading. They are forever in the blurry "in the process of downloading" state. Only a shutdown and restart of telegram solves the problem. Then the button would help. If the issues are unrelated then it won't fix everybodies problem

[jeffythedragonslayer]

For someone to code the button's onclick event to get it to free the memory, we need to know what the leaking buffer's memory address is and how big it is. And at that point we might as well just free it when someone closes the channel and not have a separate button at all. What you're describing almost sounds like manual garbage collection to me though.

[gaplo917]

As I remember my telegram desktop did close about 1 week. The memory can unexpectedly go high to 9.8 GB!!

[as3ii]

I've noticed a memory leak (I don't know if it is related with cached images or something else). I'm using telegram 2.1.0 on arch linux. I don't know if it will be helpful, but I've used telegram-desktop for a couple of hours logging memory leaks with
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind-out.txt telegram-desktop
Here the resulting log file: valgrind-out.txt

[EndrII]

telegram use 800 mb RAM

[oshanz]

I thought electron apps are worst.
my slack app always under 400MB whatever I do around channels.
but telegram app seems never releasing memory. I have to reopen couple of times per day.

[olegon-ru]

Source : telegram-desktop-2.1.7-1.fc32.src.rpm
From repo : rpmfusion-free-updates
5.6.14-300.fc32.x86_64, Fedora 32 Gnome, all updates included
The same trouble... I have to killall telegram-desktop every evening to prevent unstoppable memory leakage and can use it only in restricted mode on notebook with 4Gb memory.

[Germano0]

Telegram 2.4.2 made my system (Fedora 32) with 16 GB RAM and 32 GB SSD swap, run out of memory.
No time to get any useful debuginfo since everytime I experience this problem I have to kill the process from TTY

[jeffythedragonslayer]

Is the Fedora OOM killer enabled?

On Sat, Oct 3, 2020, 6:27 AM Germano Massullo [e-mail]
wrote:

Telegram 2.4.2 made my system (Fedora 32) with 16 GB RAM and 32 GB SSD
swap, run out of memory.
No time to get any useful debuginfo since everytime I experience this
problem I have to kill the process from TTY

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/7361#issuecomment-703082074,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADFDUGTCSYXIHSHE4FZLUTDSI3377ANCNFSM4LFVSUSQ
.

[soredake]

Same happens when scrolling channel with large videos (2.3gb after five minutes)

[oshanz]

1.6gb for a day, Fedora 33