The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Раздел полезных советов: Эксперименты по борьбе с утечками памяти Telegram Desktop"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Эксперименты по борьбе с утечками памяти Telegram Desktop"  +/
Сообщение от auto_tips (??), 14-Май-21, 00:16 
Известны жалобы о больших утечках памяти в Telegram Desktop на Linux, не наблюдаемых в таких же объемах на других ОС, в частности Windows и FreeBSD. В рамках проверки гипотезы о том, что дело в реализации системного аллокатора и настройках автопроигрывания медиа, помогающие автору TDesktop [[https://t.me/kepka_support/42874 энтузиасты]] создали канал https://t.me/tdesktop_crash, продолжительная прокрутка которого должна приводить к утечкам памяти. При этом при нормальном поведении закрытие этого окна (переключение на другой чат) должна освобождать память.

Выяснилось, что на Windows при переключении чата память освобождается, на обычном Linux glibc - не освобождаются несколько Гб, но происходит почти полное освобождение через некоторое время, если запустить Telegram Desktop с аллокатором jemalloc из FreeBSD (пример для Debian, подробности
см. в [[https://github.com/jemalloc/jemalloc/wiki/Getting-Started документации jemalloc]]):

  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 telegram-desktop

Аналогичные (или даже лучше) результаты были получены на дистрибутивах без glibc, например [[https://alpinelinux.org/ Alpine]], где применяется musl.

Поскольку в разных дистрибутивах могут быть разные политики по сборке (статически и без), и майнтейнеры могут испытывать проблемы с включением решения, а современные аллокаторы сложны, и, возможно, glibc malloc может быть соответствующим образом настроен, к экспериментам и помощи приглашаются знатоки.

URL: https://t.me/tdesktop_crash
Обсуждается: https://www.opennet.ru/tips/info/3184.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Май-21, 00:16   +/
Что-то я не понял - проблема в glibc или в Telegram?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Аноним (2), 14-Май-21, 05:12   +/
В телеграм конечно же проблема, пусть его разработчики чинят, но им пофиг
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4

3. Сообщение от Аноним (3), 14-Май-21, 10:03   +/
см malloc_trim()
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от nuclightemail (??), 14-Май-21, 20:15   +/
В glibc конечно же. Переменная окружения MALLOC_MMAP_THRESHOLD_=128 вроде более лучшие результаты выдает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5

5. Сообщение от slepnoga (??), 15-Май-21, 13:20   +/
Течет телега, а виноват глибц.
Естественно, ведь телега это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #7

6. Сообщение от PedeRust (?), 15-Май-21, 20:57   +/
glibc срочно на расте переписать, иначе пользоваться этим заскорузлым говном невозможно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #67

7. Сообщение от nuclightemail (??), 16-Май-21, 10:04   +/
Так у меня на фре нет glibc, и телега не течёт, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #14

8. Сообщение от Аноним (8), 16-Май-21, 21:10   +/
Лучше сменить мессенджер. Толку помогать разработчикам телеги если им самим плевать на свой мессенджер. Я уже не говорю о сливах, привязки с номеру, отсутствия реальной приватности, закрытых серверах и никакой противодействии блокировкам (заставить пользовтелей использовать vpn это не заслуга телеграма, а телеграм прокси это профанация отслеживаемая по щелчку пальцев (т.е. даже вреднее чем ее отсутствие)) и тд и тп.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #27

9. Сообщение от Аноним (1), 16-Май-21, 23:35   +/
А что вместо? Signal? Matrix?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10, #12, #43, #48, #72

10. Сообщение от отвечатель (?), 17-Май-21, 00:28   +/
сигнал - гораздо более безопасный месенджер
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15

11. Сообщение от Аноним (11), 17-Май-21, 08:51   –1 +/
>но происходит почти полное освобождение через некоторое время, если запустить Telegram Desktop с аллокатором jemalloc из FreeBSD

Firefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но не крешится), а на Линуксе текёт (жрёт память, при этом ещё и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо СПО - говно:

>современные аллокаторы сложны

... и требуют инвестиций в разработку и отладку, которые по карману только крупным корпорациями вроде Microsoft и Apple, которые своими know how бесплатно не поделятся.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #36

12. Сообщение от КО (?), 17-Май-21, 17:47   +/
https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...
Вон Jitsi твой телефон не нужен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

13. Сообщение от Аноним (1), 17-Май-21, 18:20   +/
Matrix (Element) тоже не нужен, но он вроде как пофункциональнее будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

14. Сообщение от Аноним (14), 18-Май-21, 22:22   +/
У меня такая же нога и не болит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

15. Сообщение от Аноним (15), 19-Май-21, 23:14   +/
Ага, в котором на Андроиде даже нельзя зарегаться без Google Apps.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #25

16. Сообщение от Crazy Alex (ok), 20-Май-21, 12:25   +/
Видимо ты тролль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #30, #41

17. Сообщение от timur.davletshin (ok), 21-Май-21, 08:38   +/
Всё бы классно, но jemalloc на холодном старте заметно более прожорлив, чем умолчальный аллокатор в относительно новых версиях glibc (имя ему pmalloc2, если память не врёт). Раньше был смысл в таких телодвижениях, т.к. jemalloc был более производителен на SMP, но сейчас разница производительности нивелирована (с 2.26 версии). Лично у меня на разница в потреблении памяти на Debian 10 достигает 40-50% не в пользу jemalloc на холодном старте, но через какое-то время падает, но тоже не в пользу jemalloc. Увы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

18. Сообщение от YAAnonim (?), 21-Май-21, 18:30   +/
Читать документацию пробовали? То что он ее сразу не освобождает не значит что она не доступна для выделения (для процесса освобожденная память помечается свободной для выделения). Это не утечка - это ленивое освобождение.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21

19. Сообщение от Аноним (24), 21-Май-21, 21:06   +1 +/
У нас в этих наших линуксах всё так "течёт".

Нужно понимать как работает malloc. При выделение памяти маллоком, выделает её не ядро, а выделяет реализация маллок из glibc, а если памяти уже выделенной в процесс не достаточно, то глбиц просит ещё отсыпать у ядра. Но при освобождении не возвращает ядру по разным причинам(в многом виновата фрагментация памяти внутри процесса)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #32

20. Сообщение от Аноним (20), 21-Май-21, 21:23   +1 +/
"Фрагментация памяти", слышали про такое?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #31, #42

21. Сообщение от Аноним (21), 22-Май-21, 10:36   +/
Для выделение каким процессом? В каком количестве? Твоя диванная экспертиза делает мне смешно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24

22. Сообщение от Аноним (1), 22-Май-21, 18:04   +/
"Что течёт? — Всё течёт!" (из к/ф "Глубже!")

Так течёт или не течёт?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23

23. Сообщение от Аноним (24), 23-Май-21, 02:10   +/
Да, и вина всему частые мелкие аллокации скриптовых языков, на коих всё понаписано, что kde, что gnome.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (24), 23-Май-21, 02:15   +1 +/
Предыдущий оратор наверно имел ввиду то, что освобождённая память в процессе в большинстве случаев доступна для повторного выделения внутри процесса. Конечно при условии, что выделенные "чанки" не на столько малы, что могут быть переиспользованы крайне редко и "зависают" во фрагментированном хипе. Тогда это можно считать утечкой, в чем косвенно виновата и сама программа, а не только глибц, так как не учитывает этот момент и выделяет по 3 байта маллоком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от Аноним (25), 23-Май-21, 17:13   +/
И, внезапно, без номера телефона
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #37

26. Сообщение от Ан (??), 24-Май-21, 10:58   +/
нет а что это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

27. Сообщение от Аноним (27), 24-Май-21, 11:58   +/
А вместе с мессенджером поменять круг общения, да? А если я не хочу и меня устраивают эти родители и жена?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #55

28. Сообщение от макпыф (ok), 25-Май-21, 13:42   +/
надеюсь вы шутите
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

30. Сообщение от Аноним (30), 25-Май-21, 18:47   +/
> Видимо ты тролль

Вдимо нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

31. Сообщение от acroobat (ok), 26-Май-21, 11:28   +/
tmpfs?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

32. Сообщение от X86 (ok), 27-Май-21, 14:01   +/
Значит просто нужно больше памяти
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

35. Сообщение от nuclightemail (??), 29-Май-21, 18:47   +/
Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc телега не течет, со свежей течет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

36. Сообщение от nuclightemail (??), 29-Май-21, 18:48   +/
> Firefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но
> не крешится), а на Линуксе текёт (жрёт память, при этом ещё
> и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо
> СПО - говно:

Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc (4) телега не течет, со свежей (5) течет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

37. Сообщение от незнаю (?), 29-Май-21, 22:08   +/
Этот номер еще и нельзя скрыть, насколько помню. И правда безопасный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

41. Сообщение от yourc (?), 30-Май-21, 18:05   +/
> Видимо ты тролль

Это пох, здешний виндузятник. Здорово тралит новую волну линуксоидов) Скиллы эникейские, но умеет притворяться щарящим, чем люто доставляет. Енжой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #59

42. Сообщение от anonymous (??), 06-Июн-21, 12:45   +/
Скорее всего фрагментация.

Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc не вызовет munmap(), если последний чанк помечен как non-free. Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы, на которые можно вызвать munmap().  

Проблема заметна в долго выполняющихся программах на C++: браузеры, мессенджеры и т.д.
В Firefox не просто так поменяли аллокатор из glibc на jemalloc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #46

43. Сообщение от Мяукающий Котик (?), 08-Июн-21, 14:57   +/
Discord. Номер телефона не нужен. Можно включить нормальную двухфакторку с одноразовыми кодами. Доступа к контактам не требует. Если никуда не выкладывать ссылку на сервер (или вообще не создавать ссылку), то его невозможно найти. Удобная организация любого количества каналов и их групп в рамках одного сервера (вместо кучи различных чатов, как в других мессенджерах)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #44, #51, #66

44. Сообщение от rem (??), 10-Июн-21, 11:45   +/
а еще он на модном электроне, который не умеет под вяленого, зато умеет жрать 300 мегов рамы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

45. Сообщение от pavlinux (ok), 10-Июн-21, 15:38   +/
Блин, посаны..., исходники всего этого добра доступны, какого ..уя вы целый месяц соплю жуёте?
Гадают, бзд/жлибс/телега... Не можете отловить мямлика?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #60

46. Сообщение от pavlinux (ok), 10-Июн-21, 22:17   –1 +/
> Скорее всего фрагментация.
> Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
> Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc
> не вызовет munmap(), если последний чанк помечен как non-free.

Спецом от anonymous пишите, чтоб не позориться от этого бреда?

Какая пля куча malloc?  :рукалицо:  
Сколько malloc(), столько же и free(), нет никакой кучи malloc  


> Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы,  
> на которые можно вызвать munmap().

Чo? освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;

Хватить пиз....олить, тиоретеги... Где отладка с valgring, duma, mtrace, tcmalloc, heaptrack,...  

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #50, #56

47. Сообщение от pavlinux (ok), 10-Июн-21, 22:39   +1 +/
Сцк, пля, этот так сложно было?

$ heaptrack /opt/Telegram/Telegram.exec
heaptrack output will be written to "/tmp/heaptrack/heaptrack.Telegram.exec.20713.zst"

heaptrack stats:
    allocations:              4368434
    leaked allocations:       15823
    temporary allocations:    470613
Heaptrack finished! Now run the following to investigate the data:

$ heaptrack --analyze "/tmp/heaptrack/heaptrack.Telegram.exec.20713.zst"


total runtime: 142.65s.
bytes allocated in total (ignoring deallocations): 7.04GB (49.39MB/s)
calls to allocation functions: 4368434 (30623/s)
temporary memory allocations: 482100 (3379/s)
peak heap memory consumption: 1.58GB
peak RSS (including heaptrack overhead): 21.56GB
total memory leaked: 10.09MB


https://pastebin.pl/view/c64c21a1

15000 протеканий!!! Glibc виноват, конэшн.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49, #52

48. Сообщение от Аноним (48), 11-Июн-21, 00:13   +/
Matrix его используют уже много где, в том числе как правительственный месенджер во франции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

49. Сообщение от Аноним (1), 12-Июн-21, 10:33   +1 +/
А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53

50. Сообщение от anonymous (??), 14-Июн-21, 14:27   +/
> Какая пля куча malloc?  :рукалицо:
> Сколько malloc(), столько же и free(), нет никакой кучи malloc  

heap.

Изучите, как устроен аллокатор в glibc (искать по словам ptmalloc, dlmalloc) и еще раз внимательно перечитайте сообщение выше.

> освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;

Идите учить матчасть. free() в glibc не всегда приводит к munmap().

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

51. Сообщение от sage (??), 14-Июн-21, 14:32   +/
Discord часто требует номер телефона.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #54

52. Сообщение от anonymous (??), 14-Июн-21, 14:35   +/
> peak heap memory consumption: 1.58GB
> peak RSS (including heaptrack overhead): 21.56GB
> total memory leaked: 10.09MB

А теперь сравните реальные утечки 10.09MB с peak heap memory consumption = 1.58G
и внимательно перечитайте текст новости:

> Выяснилось, что на Windows при переключении чата память освобождается, на
> обычном Linux glibc - не освобождаются несколько Гб, но происходит почти полное
> освобождение через некоторое время, если запустить Telegram Desktop с
> аллокатором jemalloc из FreeBSD ...
> ...
> Аналогичные (или даже лучше) результаты были получены на дистрибутивах без
> glibc, например Alpine, где применяется musl.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

53. Сообщение от anonymous (??), 14-Июн-21, 14:50   +/
> А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?

Будет на любую аллокацию > 128B делать mmap() новой страницы, оверхед в (размер страницы / 128) раз. RSS распухнет в десятки раз, но после free() память будет возвращаться через munmap().

Есть аллокаторы (например, openbsd malloc), в которых для аллокаций данного размера создаются отдельные кучи через mmap(), и при вызове free() на все аллокации, размещенные в данной странице, немедленно вызывается munmap().

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

54. Сообщение от Мяукающий Котик (?), 14-Июн-21, 17:32   +/
> Discord часто требует номер телефона.

Не требует, а всего лишь предлагает один раз ввести. От этого можно отказаться

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #61

55. Сообщение от Аноним (55), 15-Июн-21, 04:12   +/
Поменяйте только клиент. Есть opensource клиенты.
Plus Messenger на Андроид даже более функциональный, чем оффициальный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

56. Сообщение от Аноним (56), 16-Июн-21, 18:00   +1 +/
Когда хотел поумничать, но в результате обделался
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #57

57. Сообщение от anonymous (??), 16-Июн-21, 21:43   +/
> Когда хотел поумничать, но в результате обделался

Минуты позора спасают годы жизни (c)

Проблема с фрагментацией кучи в аллокаторе glibc известна как минимум 20 лет как.
Частично решается применением специализированных аллокаторов типа tcmalloc, jemalloc в специфическом софте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

58. Сообщение от Федор Михалыч (?), 24-Июн-21, 14:35   +/
в винде тоже падает хорошо
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62

59. Сообщение от Michael Shigorinemail (ok), 24-Июн-21, 22:10   +/
Чадо, тот "пох", который тут оригинальный -- он тролль ещё тот, да только вот не ребёнку, который глазки смайликам выкалывает, про старпёрские m4d sk1llz рассусоливать.  В отличие от нас с Вами он наверняка способен и аллокатор написать (я знаю, что это за человек).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

60. Сообщение от Michael Shigorinemail (ok), 24-Июн-21, 22:15   +/
> Блин, посаны..., исходники всего этого добра доступны,
> какого ..уя вы целый месяц соплю жуёте?

Ну спросите начальство, вдруг благоволят выделить рабочего времени на отладку/отлов/исправление проблемы и запихивание патча в апстрим ;-)  Это ж целое достижение будет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

61. Сообщение от sage (??), 28-Июн-21, 15:19   +/
От этого нельзя отказаться, он перестаёт работать, пока не введёшь и не подтвердишь через СМС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

62. Сообщение от нворд (?), 29-Июн-21, 15:15   +/
Зато жрёт меньше.
А под линем жрёт больше но гораздо меньше падает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

63. Сообщение от Аноним (63), 12-Июл-21, 16:25   +/
Эксперименты по борьбе... результатов не дали.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64

64. Сообщение от ilyafedin (ok), 14-Июл-21, 23:07   +/
Почему нет, в 2.8 прицепили кастомный аллокатор, теперь нормально работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

66. Сообщение от Капитан (??), 15-Июл-21, 12:48   +/
Уже бы сразу товарищу майору сообщения отправлял.
spyware.neocities.org/articles/discord.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

67. Сообщение от Shshsh (?), 05-Авг-21, 08:36   +/
В Rust'е алокатор ещё хуже работает, если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

70. Сообщение от Аноним (70), 09-Окт-21, 01:05   +/
hardened_malloc
https://github.com/GrapheneOS/hardened_malloc
Ответить | Правка | Наверх | Cообщить модератору

72. Сообщение от develop7 (ok), 08-Ноя-21, 14:25   +/
Threema не нужен ни телефон, ни email. Jami (ex-Ring) тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру