A rapid RAM usage burst when downloading and displaying GIFs

[bodqhrohro]

Steps to reproduce

I'm still not sure about exact conditions, despite I experience this for many months. It happens with GIFs and sometimes with static images too. It's enough to switch to a chat with a preview or scroll the history up. The burst happens nearly when a blurred preview is shown a spinner over while a full version of a media file is downloaded.

Another precondition is having the RAM almost full, with several hundreds of MBs of free RAM remaining. Here are my memory management settings:

vm.swappiness=200
vm.overcommit_memory=1
vm.overcommit_ratio=200
vm.dirty_background_bytes=2097152
vm.dirty_bytes=16777216
vm.dirty_expire_centisecs=1000
vm.vfs_cache_pressure=20

Also ZRam enabled and no disk swap.

Expected behaviour

No accidental RAM consumption growth.

Actual behaviour

If I don't notice the burst in a few seconds and kill TelegramDesktop immediately, things go rapid. The system freezes so fast and deep (with Load Average going near 100–200 on a 2-core CPU) that I cannot even switch to a text TTY anymore, even in the raw (Alt+SysRq+R) keyboard mode when kernel hotkeys (Alt+F) are invoked rather than X.Org ones (Ctrl+Alt+F). I can only invoke the manual OOM killer (Alt+SysRq+F), and as TelegramDesktop gains a very low OOM score, I have to hit it tens of times and kill almost all userspace processes, sometimes even such important ones as dbus-daemon, until TelegramDesktop process is finally reached.

An example of post-mortem:

root@localhost:~# dmesg|grep 'Out of'[3758770.422558] Out of memory: Killed process 1679645 (chromium) total-vm:1197432kB, anon-rss:0kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:712kB oom_score_adj:200
[3758884.174350] Out of memory: Killed process 2623593 (dbus-daemon) total-vm:9940kB, anon-rss:292kB, file-rss:364kB, shmem-rss:0kB, UID:1000 pgtables:52kB oom_score_adj:200
[3758900.806853] Out of memory: Killed process 2614219 (Telegram) total-vm:3529612kB, anon-rss:155832kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:6060kB oom_score_adj:0
[3758955.038749] Out of memory: Killed process 2623613 (dbus-daemon) total-vm:9852kB, anon-rss:188kB, file-rss:1088kB, shmem-rss:0kB, UID:1000 pgtables:56kB oom_score_adj:200
[3758966.566525] Out of memory: Killed process 2623616 (pulseaudio) total-vm:12836kB, anon-rss:288kB, file-rss:1448kB, shmem-rss:0kB, UID:1000 pgtables:56kB oom_score_adj:200

A GIF on which the bug is reproduced more-or-less reliably (1.6 GB RES on one run, just 400 MB RES on next run, how does that even work?)

https://user-images.githubusercontent.com/2134486/186154052-ccda030c-1a2f-465b-839e-189db9a10513.mp4

Operating system

Debian GNU/Linux 12, compiz-reloaded 0.8.18

Version of Telegram Desktop

4.1.1

Installation source

Static binary from official website

Logs

No response

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bodqhrohro]

Not sure if this is still relevant, but probably yes. I changed the hardware since the report, and TelegramDesktop behaves totally different there: it occupies twice as more RAM at the start (460 MB), and occasionally jumps to 601 MB when opening a chat with the same GIF, which makes no serious consequences here, but may do on a weaker hardware. Possibly the time required to display the spinner is significant too, as it's shorter here.

[bodqhrohro]

It also definitely happens only when a GIF is autoplayed. If I raise the autoplay limit and run Telegram outside of a memory-limited cgroup, I managed to get a rapid burst to ≈680 MB on this hardware with a specially crafted 5MB highres GIF:

https://user-images.githubusercontent.com/2134486/220025208-71a92e4f-9e19-444b-9d84-732248c7eda1.MP4

Still far from the aforementioned number though.

[bodqhrohro]

The machine where I catched it first has a E450 CPU, 6GB of overfilled RAM and a HDD.

[c0re100]

https://github.com/telegramdesktop/tdesktop/issues/7287#issuecomment-639019925

[bodqhrohro]

#7287 (comment)

And?

If TelegramDesktop needs too much RAM to cache the video frames, it should better show them with lags than put the whole system down.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bodqhrohro]

Seems to be relevant in 4.9.1, I've just checked the last GIF and got a burst from 400 MB to 533 MB.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bodqhrohro]

Still relevant, 491 MB → 611 MB rapidly.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bodqhrohro]

Still relevant, RAM usage fluctuates between 439 MB and 517 MB when I switch from and to a chat with such a GIF.