Известны жалобы о больших утечках памяти в 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
Обсуждается: http://www.opennet.me/tips/info/3184.shtml
Что-то я не понял - проблема в glibc или в Telegram?
В телеграм конечно же проблема, пусть его разработчики чинят, но им пофиг
В glibc конечно же. Переменная окружения MALLOC_MMAP_THRESHOLD_=128 вроде более лучшие результаты выдает.
Течет телега, а виноват глибц.
Естественно, ведь телега это.
Так у меня на фре нет glibc, и телега не течёт, например.
У меня такая же нога и не болит.
см malloc_trim()
glibc срочно на расте переписать, иначе пользоваться этим заскорузлым говном невозможно
надеюсь вы шутите
В Rust'е алокатор ещё хуже работает, если что.
Лучше сменить мессенджер. Толку помогать разработчикам телеги если им самим плевать на свой мессенджер. Я уже не говорю о сливах, привязки с номеру, отсутствия реальной приватности, закрытых серверах и никакой противодействии блокировкам (заставить пользовтелей использовать vpn это не заслуга телеграма, а телеграм прокси это профанация отслеживаемая по щелчку пальцев (т.е. даже вреднее чем ее отсутствие)) и тд и тп.
А что вместо? Signal? Matrix?
сигнал - гораздо более безопасный месенджер
Ага, в котором на Андроиде даже нельзя зарегаться без Google Apps.
И, внезапно, без номера телефона
Этот номер еще и нельзя скрыть, насколько помню. И правда безопасный.
https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...
Вон Jitsi твой телефон не нужен
Matrix (Element) тоже не нужен, но он вроде как пофункциональнее будет.
Discord. Номер телефона не нужен. Можно включить нормальную двухфакторку с одноразовыми кодами. Доступа к контактам не требует. Если никуда не выкладывать ссылку на сервер (или вообще не создавать ссылку), то его невозможно найти. Удобная организация любого количества каналов и их групп в рамках одного сервера (вместо кучи различных чатов, как в других мессенджерах)
а еще он на модном электроне, который не умеет под вяленого, зато умеет жрать 300 мегов рамы
Discord часто требует номер телефона.
> Discord часто требует номер телефона.Не требует, а всего лишь предлагает один раз ввести. От этого можно отказаться
От этого нельзя отказаться, он перестаёт работать, пока не введёшь и не подтвердишь через СМС.
Уже бы сразу товарищу майору сообщения отправлял.
spyware.neocities.org/articles/discord.html
Matrix его используют уже много где, в том числе как правительственный месенджер во франции.
Threema не нужен ни телефон, ни email. Jami (ex-Ring) тоже.
А вместе с мессенджером поменять круг общения, да? А если я не хочу и меня устраивают эти родители и жена?
Поменяйте только клиент. Есть opensource клиенты.
Plus Messenger на Андроид даже более функциональный, чем оффициальный.
>но происходит почти полное освобождение через некоторое время, если запустить Telegram Desktop с аллокатором jemalloc из FreeBSDFirefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но не крешится), а на Линуксе текёт (жрёт память, при этом ещё и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо СПО - говно:
>современные аллокаторы сложны
... и требуют инвестиций в разработку и отладку, которые по карману только крупным корпорациями вроде Microsoft и Apple, которые своими know how бесплатно не поделятся.
Видимо ты тролль
> Видимо ты тролльВдимо нет.
> Видимо ты тролльЭто пох, здешний виндузятник. Здорово тралит новую волну линуксоидов) Скиллы эникейские, но умеет притворяться щарящим, чем люто доставляет. Енжой.
Чадо, тот "пох", который тут оригинальный -- он тролль ещё тот, да только вот не ребёнку, который глазки смайликам выкалывает, про старпёрские m4d sk1llz рассусоливать. В отличие от нас с Вами он наверняка способен и аллокатор написать (я знаю, что это за человек).
> Firefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но
> не крешится), а на Линуксе текёт (жрёт память, при этом ещё
> и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо
> СПО - говно:Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc (4) телега не течет, со свежей (5) течет.
Всё бы классно, но jemalloc на холодном старте заметно более прожорлив, чем умолчальный аллокатор в относительно новых версиях glibc (имя ему pmalloc2, если память не врёт). Раньше был смысл в таких телодвижениях, т.к. jemalloc был более производителен на SMP, но сейчас разница производительности нивелирована (с 2.26 версии). Лично у меня на разница в потреблении памяти на Debian 10 достигает 40-50% не в пользу jemalloc на холодном старте, но через какое-то время падает, но тоже не в пользу jemalloc. Увы.
Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc телега не течет, со свежей течет.
Читать документацию пробовали? То что он ее сразу не освобождает не значит что она не доступна для выделения (для процесса освобожденная память помечается свободной для выделения). Это не утечка - это ленивое освобождение.
Для выделение каким процессом? В каком количестве? Твоя диванная экспертиза делает мне смешно.
Предыдущий оратор наверно имел ввиду то, что освобождённая память в процессе в большинстве случаев доступна для повторного выделения внутри процесса. Конечно при условии, что выделенные "чанки" не на столько малы, что могут быть переиспользованы крайне редко и "зависают" во фрагментированном хипе. Тогда это можно считать утечкой, в чем косвенно виновата и сама программа, а не только глибц, так как не учитывает этот момент и выделяет по 3 байта маллоком.
У нас в этих наших линуксах всё так "течёт".Нужно понимать как работает malloc. При выделение памяти маллоком, выделает её не ядро, а выделяет реализация маллок из glibc, а если памяти уже выделенной в процесс не достаточно, то глбиц просит ещё отсыпать у ядра. Но при освобождении не возвращает ядру по разным причинам(в многом виновата фрагментация памяти внутри процесса)
"Что течёт? — Всё течёт!" (из к/ф "Глубже!")Так течёт или не течёт?
Да, и вина всему частые мелкие аллокации скриптовых языков, на коих всё понаписано, что kde, что gnome.
Значит просто нужно больше памяти
"Фрагментация памяти", слышали про такое?
нет а что это?
tmpfs?
Скорее всего фрагментация.Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc не вызовет munmap(), если последний чанк помечен как non-free. Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы, на которые можно вызвать munmap().Проблема заметна в долго выполняющихся программах на C++: браузеры, мессенджеры и т.д.
В Firefox не просто так поменяли аллокатор из glibc на jemalloc.
> Скорее всего фрагментация.
> Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
> Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc
> не вызовет munmap(), если последний чанк помечен как non-free.Спецом от anonymous пишите, чтоб не позориться от этого бреда?
Какая пля куча malloc? :рукалицо:
Сколько malloc(), столько же и free(), нет никакой кучи malloc
> Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы,
> на которые можно вызвать munmap().Чo? освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;
Хватить пиз....олить, тиоретеги... Где отладка с valgring, duma, mtrace, tcmalloc, heaptrack,...
> Какая пля куча malloc? :рукалицо:
> Сколько malloc(), столько же и free(), нет никакой кучи mallocheap.
Изучите, как устроен аллокатор в glibc (искать по словам ptmalloc, dlmalloc) и еще раз внимательно перечитайте сообщение выше.
> освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;
Идите учить матчасть. free() в glibc не всегда приводит к munmap().
Когда хотел поумничать, но в результате обделался
> Когда хотел поумничать, но в результате обделалсяМинуты позора спасают годы жизни (c)
Проблема с фрагментацией кучи в аллокаторе glibc известна как минимум 20 лет как.
Частично решается применением специализированных аллокаторов типа tcmalloc, jemalloc в специфическом софте.
Блин, посаны..., исходники всего этого добра доступны, какого ..уя вы целый месяц соплю жуёте?
Гадают, бзд/жлибс/телега... Не можете отловить мямлика?
> Блин, посаны..., исходники всего этого добра доступны,
> какого ..уя вы целый месяц соплю жуёте?Ну спросите начальство, вдруг благоволят выделить рабочего времени на отладку/отлов/исправление проблемы и запихивание патча в апстрим ;-) Это ж целое достижение будет.
Сцк, пля, этот так сложно было?$ 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/c64c21a115000 протеканий!!! Glibc виноват, конэшн.
А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?
> А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?Будет на любую аллокацию > 128B делать mmap() новой страницы, оверхед в (размер страницы / 128) раз. RSS распухнет в десятки раз, но после free() память будет возвращаться через munmap().
Есть аллокаторы (например, openbsd malloc), в которых для аллокаций данного размера создаются отдельные кучи через mmap(), и при вызове free() на все аллокации, размещенные в данной странице, немедленно вызывается munmap().
> 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.
в винде тоже падает хорошо
Зато жрёт меньше.
А под линем жрёт больше но гораздо меньше падает.
Эксперименты по борьбе... результатов не дали.
Почему нет, в 2.8 прицепили кастомный аллокатор, теперь нормально работает
hardened_malloc
https://github.com/GrapheneOS/hardened_malloc