Browsers (f???ng memory leaks)

[mr.qweo]

Сорри за описание темы,но эти утечки памяти уже достали. С тех пор как из консоли я перешёл в иксы и сменил Links2 на firefox эти memory leaks просто меня преследуют ) firefox отжирал (по словам top'а) до 50% процентов памяти,что,учитывая что у меня 1 GB RAM,очень много...Никакие настройки,типа отключения кеширования страниц и прочего,что я нашёл в google,и поэтому я перешёл на Mozilla Browser.Первое время он просто летал (кстати,и в фоксе,и в mozilla browser'е я не ставил не одного расширения,регулярно чистил историю закачек,посещений,даже "плюшки") пока (сегодня) всё не начало тормозить ТАК.....Задержка между вводом символа и отображением на экране была в несколько секунд! Я попытался запустить top,которому,чтобы запуститься,пришлось убить "соседний" aterm,screen и все запущеные в нём програмы (irssi,man,несколько экземпляров zsh of course ) ).По данным top'а,f*g mozilla browser сжирал 94% памяти,всё того же гига!!! Даже не знаю,что делать...Скорее всего замена на другой браузер ничего не даст - 90% из них основаны на горячо Gecko,а я думаю,что это всё-таки проблемы движка,а не браузера.Значит остался только Links? Или просто надо обновить драйвер /dev/hands?
P.S.: да,я юзаю много табов

[boombick]

К сожалению, с лисичкой наблюдаются подобные проблемы Пересел для серфинга на оперу, жить стало полегче... Хотя функционала не хватает (Это не провокация холивара, а имхо)...

[mr.qweo]

Интересно,может быть установить браузеру квоту на использование памяти?Вроде бы фокс при меньшем количестве памяти меньше её расходует....
И ещё,если это действительно проблемы в движке...Кто-нибудь знает KHTML-based browser не требующий qt?

[zov]

Можно сантехнику вставить своих 5 копейков ? ©

Это не проблема конкретного браузера.

Виновата реализация *alloc()/free() в glibc.
При вызове malloc(size) с size << MMAP_THRESHOLD malloc использует sbrk() для увеличения размера динамической кучи, если в куче нет свободного chunk'а > size. В таком случае, при вызове free() куча уменьшается, только если освобождается кусок, стоящий в хвосте кучи.

Браузер в процессе работы alloc-ирует много кусков в среднем по ~20 байт и освобождает их, вообще говоря, не с конца кучи. В результате, куча имеет дырявый вид вроде ###---##-####-#----------###---#####, где '#' обозначает занятый chunk, '-' -- свободный.

В сеансе mozilla-*, konqueror, opera, etc. размер вирт. памяти растет, и не может уменьшится на ожидаемую величину, напр., при закрытии страницы/вкладки/окна.

Проверка:

- отключаем все cache в mozilla;
1. запускаем mozilla с about:blank, замечаем размер вирт.памяти (код + данные + стек);
2. открываем ~30 страниц во вкладках, опять отмечаем VM;
3. закрываем все вкладки, кроме одной, замечаем VM.

VM(3) ~ VM(2) >> VM(1) , а ожидается, что на шаге 3 VM должно вернуться к значению на шаге 1.

To же самое с konqueror, opera.

На OpenBSD 3.8, 3.9 mozilla при закрытии страниц/вкладок возвращает память системе в ожидаемом количестве, т.к. там *alloc() использует _толькo_ mmap() и строит много мелких куч вместо одной большой (как в linux).

На Windows 2000 тоже проблемы нет.

См. обсуждения в bugzilla.mozilla.org, напр. https://bugzilla.mozilla.org/show_bug.cgi?id=324081

За этот баг желательно проголосовать на bugzilla всем пользующим mozilla-* под gnu/linux.




ЗЫ к "настоящим" утечкам памяти это _никакого_ отношения не имеет, проверено на mozilla с leak detection tools.

[mr.qweo]

хм,интересно,есть ли патчи для ядра Linux,организующие OpenBSD-like алгоритм работы с памятью....

[zov]

Ядро не при чем. Надо переписывать glibc.

Вариант: собрать в linux *alloc/free из OpenBSD ( http://www.openbsd.org/cgi-bin/cvsweb/~che...type=text/plain ) в отдельную б-ку и % LD_PRELOAD=./openbsd_alloc_free.so mozilla

ЗЫ ядру может поплохеть от немеряного кол-ва вызовов mmap(), не проверено.

[mr.qweo]

Ядро не при чем. Надо переписывать glibc.

Вариант: собрать в linux *alloc/free из OpenBSD ( http://www.openbsd.org/cgi-bin/cvsweb/~che...type=text/plain ) в отдельную б-ку и % LD_PRELOAD=./openbsd_alloc_free.so mozilla

ЗЫ ядру может поплохеть от немеряного кол-ва вызовов mmap(), не проверено.

Код: Выделить всё

OpenBSDMalloc.c:266: error: 'PGSHIFT' undeclared (first use in this function)

[17:39] (~src/malloc) %gcc -DMALLOC_STATS -shared -fpic OpenBSDMalloc.c -o OpenBSDMalloc.so 2>&1 | grep PGSHIFT | wc -l
11
[17:39] (~src/malloc) %

[zov]

Дык творчески собирать надо

[Skull]

К сожалению, с лисичкой наблюдаются подобные проблемы Пересел для серфинга на оперу, жить стало полегче... Хотя функционала не хватает (Это не провокация холивара, а имхо)...

Можно Konqueror посоветовать. Тоже memory leak не наблюдается.

[zov]

К memory leaks обсуждаемый эффект не относится. konqueror ведет себя так же.

[t.t]

P.S.: да,я юзаю много табов

↑

Тогда только один вариант: опера. Проверено на практике. Единственный браузер (кроме elinks ), который не начинает жутко тормозить при открытых нескольких десятках вкладок.

Это не проблема конкретного браузера.

↑

Да-да-да, конечно-конечно. Только почему-то опера при открытых 50-60 вкладках никогда не отжирала больше 200, в редких случаях 250, метров памяти, а огнелис уже при двух-трёх десятках сожрал почти все присутствующие 512М.

[serzh-z]

а огнелис уже при двух-трёх десятках сожрал почти все присутствующие 512М.

В FF куча плагинов, причём они написаны на JS. Неизбежные тормоза - обратная сторона этой гибкости. <_< Надо полагать, что вкладками управляет тот же tabmixplus.

[zov]

Спорить не будем, лучше подумайте ©

Только почему-то опера при открытых 50-60 вкладках никогда не отжирала больше 200, в редких случаях 250, метров памяти,

Для opera на linux:
закройте эти 50-60 вкладок, кроме одной, и посмотрите, SIZE(код+данные+стек) вернулось ли от 200М к исходным 15-20M ? Или таки осталось ~200M ?

а огнелис уже при двух-трёх десятках сожрал почти все присутствующие 512М.

???

firefox-1.0.7, 30 вкладок с http://news.bbc.co.uk/ , RSS ~ 50M :

% ps -o pid,command,vsz,rss,drs -p `/sbin/pidof firefox-bin`
PID COMMAND VSZ RSS DRS
18300 /usr/lib/firefox 116080 49676 116027

Если не затруднит, приведите URL "двух-трех десятков" страниц, при одновременнном открытии коих firefox съедает 512М ?

[t.t]

Если не затруднит, приведите URL "двух-трех десятков" страниц, при одновременнном открытии коих firefox съедает 512М ?

↑

К сожалению, затруднит, т.к. давно уже им не пользуюсь. Но по-моему проблема была как раз ещё и в тех вкладках, которые я на тот момент уже закрыл.

Для opera на linux:
закройте эти 50-60 вкладок, кроме одной, и посмотрите, SIZE(код+данные+стек) вернулось ли от 200М к исходным 15-20M ? Или таки осталось ~200M ?

↑

Это я понял. А вы попробуйте другое: попробуйте оставлять firefox открытым на протяжении нескольких недель, и активно сёрфить, открывать-закрывать вкладки и т.п. Опера у меня после таких экспериментов занимала те же не более 200М; firefox приходилось перезапускать несколько раз в день. Другими словами, может ли такое быть, что опера однажды занятую память не освобождает, но может повторно использовать, а firefox не использует её повторно?

[zov]

может ли такое быть, что опера однажды занятую память не освобождает, но может повторно использовать, а firefox не использует её повторно?

leak-gauge tool (http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.pl?raw=1) не находит потерянные данные в вирт. памяти.
А при "логической" утечке он должен показать, что, грубо говоря, на new/*alloc() не сделали delete/free(), и объект завис в памяти до конца сеанса.
Действительно, если открыть ~50 вкладок в mozilla-* (SIZE ~50-60M), потом закрыть и открыть их повторно, SIZE не поднимется до ~100М, а останется на месте.

Т.о., это вопрос к *alloc()/free() в glibc.
malloc_stats() показывает, что после закрытия табов память честно free()-тся, но не может быть выброшена из arena, т.к. находится в ее середине.

Вопроса нет, напр., на OpenBSD и NT, т.к. там в RTL иначе реализованы *alloc/free.

Есть много обсуждений на mozilla.org, напр., bug #324081 : https://bugzilla.mozilla.org/show_bug.cgi?id=324081

[diesel]

Это я понял. А вы попробуйте другое: попробуйте оставлять firefox открытым на протяжении нескольких недель, и активно сёрфить, открывать-закрывать вкладки и т.п. Опера у меня после таких экспериментов занимала те же не более 200М; firefox приходилось перезапускать несколько раз в день. Другими словами, может ли такое быть, что опера однажды занятую память не освобождает, но может повторно использовать, а firefox не использует её повторно?

пробовал оставлять firefox работающим в течении двух суток, серфил не активно, просто как всегда - несколько окон(три-четыре), в каждом окне где-то по пять-десять вкладок - в итоге firefox'ом было занято около 40 Мб памяти. Firefox почти без плагинов (TabMixPlus, GSpace, ну может еще несколько). С Opera таких проблем тоже не было. Всегда удивляюсь откудова они беруться у других

[zov]

> ... Всегда удивляюсь откудова они беруться у других

Проблема не в кол-ве сожранной памяти, а в том, что браузер не может через free() ее возвратить
системе, когда она больше не нужна.

[diesel]

> ... Всегда удивляюсь откудова они беруться у других

Проблема не в кол-ве сожранной памяти, а в том, что браузер не может через free() ее возвратить
системе, когда она больше не нужна.

ну вначале говорится как раз о проблеме с колличеством сожранной памяти - 512 метров для бразуера ..это сколько ж страниц должно быть открыто одновременно Ведь из того что вы написали я так понял что браузер не возрващает память при закрытии страницы, тем не менее повтороно использовать память он умеет.

[zov]

> я так понял что браузер не возрващает память при закрытии страницы, тем не менее повтороно использовать память он умеет.

Умеет. Настолько, насколько это умеют *alloc.

А 512М он съесть, токо кто ж ему дасть ©

Больше ~120М y меня mozilla не ела, даже если работала 2 недели.
Возможно, 512М возникают у народа с >= 1G ОЗУ, с кучей расширений FF, при открывании страниц с flash , с memory cache по умолчанию от кол-ва свободной памяти и т.д.
Таки 120М тоже много, когда уже все закрыто обратно.

Если в linux пофиксят проблему с невозвратом памяти по free() при аллокации мелкими кусками, mozilla-*/konqueror/opera станут намного юзабельнее.

[mr.qweo]

> я так понял что браузер не возрващает память при закрытии страницы, тем не менее повтороно использовать память он умеет.

Умеет. Настолько, насколько это умеют *alloc.

А 512М он съесть, токо кто ж ему дасть ©

Больше ~120М y меня mozilla не ела, даже если работала 2 недели.
Возможно, 512М возникают у народа с >= 1G ОЗУ, с кучей расширений FF, при открывании страниц с flash , с memory cache по умолчанию от кол-ва свободной памяти и т.д.
Таки 120М тоже много, когда уже все закрыто обратно.

Если в linux пофиксят проблему с невозвратом памяти по free() при аллокации мелкими кусками, mozilla-*/konqueror/opera станут намного юзабельнее.

У меня ела,и ещё как (см. первый пост).Но,из того что перечислено у меня только 1GB памяти,т.к.:
1) > с кучей расширений FF - не одного не в фоксе,не в мозилле
2) при открывании страниц с flash - никаких flash,ибо gnash глючит так что (хм...),а MacromediaFlash я не использую из-за лицензии.Да и вообще страницы,которые я обычно открываю,не очень большие )
3) > с memory cache по умолчанию от кол-ва свободной памяти - что я только с этим кэшем не делал.В фоксе немного (только немного,но заметно по выводу free -m) помог параметр *max*total*,уже забыл как его...Мозилле не помог и этот параметр...

[zov]

Отрубите cache вообще:

browser.cache.disk.enable = false
browser.cache.memory.enable = false

ЗЫ 64-разряднaя система у вас? на 64-разрядных пользовал только mozilla 1.0 на OpenVMS/Alpha, там такого отжора памяти не было точно, разрядность не при делах/

Какая сборка mozilla у вас?

[mr.qweo]

Отрубите cache вообще:

browser.cache.disk.enable = false
browser.cache.memory.enable = false

ЗЫ 64-разряднaя система у вас? на 64-разрядных пользовал только mozilla 1.0 на OpenVMS/Alpha, там такого отжора памяти не было точно, разрядность не при делах/

Какая сборка mozilla у вас?

Спасибо за совет с кэшем,попробую... У меня 32х-разрядная система (я сидел на 64хбитном Debian'е,но там поддержка 32хбитного софта не доведена до ума - единственый работающий вариант - 32хбитный chroot мне не очень понравился,поэтому и использую 32хбитную версию)
Сборка Mozilla - из репозитория Debian SID - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1

[zov]

Даже при включенных cache такого потребления памяти mozilla не должна иметь.
Поставьте в ~/ сборку с mozilla.org .

[rolano]

Да уж...
1. Выделение памяти по 20 байт - это УЖОС. Если взять любой мало-мальски серьезный учебник по программированию, то там пишут, что выделение памяти из кучи сопровождается накладными расходами по учету этого процесса - всякие дескрипторы и прочая хрень тоже ведь что-то в памяти занимают. Возникает вопрос - а программисты ли писали Лисичку?
2. Такое мягко говоря вольное отношение к распределению кучи - еще один повод Мелкософту сказать, что ОпенСорс - это лажа. Удивительно, как этот баг столько времени просуществовал.

[zov]

1. Выделение памяти по 20 байт - это УЖОС.

struct bad_structure {
unsigned int m;
unsigned int n;
double x;
};
...
struct bad_structure *p = new bad_structure();
...
и так много раз.

Возникает вопрос - а программисты ли писали Лисичку?

Программист на C++ -- это звучит гордо!

Такое мягко говоря вольное отношение к распределению кучи - еще один повод Мелкософту сказать, что ОпенСорс - это лажа. Удивительно, как этот баг столько времени просуществовал.

Это не баг, это сознательная фича, чтобы аллокатор aka ptmalloc* был очень быстрым.
Это неприятно только для долгоиграющих программ, откушивающих память мелкими кусками произвольной длины с последующим free в произвольном порядке.

В X11, например, проблемы с памятью нет. X-ы не пухнуть ©

На windows выделение памяти в runtime идет на порядки медленнее. Если интересно, можно привести ссылки на сравнение скорости и накл. расходов в разных аллокаторах.

ЗЫ konqueror и opera не лучше, т.к. написаны на том же C++

[koluthcka]

еще один повод Мелкософту сказать, что ОпенСорс - это лажа

ФФ (по крайней мере у меня) в форточке ну просто летал. (версия 1.5)
так что возможно не повод.

[zov]

Там кусок glibc был кандидатом в "поводы", а не сам FF.

[polachok]

http://g.oswego.edu/dl/html/malloc.html
что скажут гуру?

[zov]

Гуру Doug Lea уже все сказал по приведенной ссылкe и в ftp://g.oswego.edu/pub/misc/malloc.c

По рабоче-крестьянски:

чтобы аллокатор Lea отдавал память ОС по free() после "мелких" аллокаций, под linux его собираем с
-DHAVE_MORECORE=0 -DHAVE_MMAP=1 \
-DHAVE_USR_INCLUDE_MALLOC_H -DUSE_DL_PREFIX -DUSE_LOCKS
и линкуем с тестом вроде:

#include <stdio.h>

#define N (1024*256)
#define SIZE (16)

char *p [N];

extern void* dlmalloc(size_t);
extern void dlfree (void*);

int main (void) {
int n, i;
for (n = 0; n < N; n++) {
if ((p[n] = dlmalloc(sizeof(char)*SIZE)) == NULL) /* malloc() D,Lea так вызывается */
break;
for (i = 0; i < SIZE; i++)
p[n][i] = '\0';
if (n % 1024 == 0)
printf("%d kB скушали \n", (n+1)*SIZE/1024);
}
for (i=0; i < n; i++) {
dlfree((void*)p[i]); /* free() D.Lea */
if (i % 1024 == 0) {
printf("%d kB освободили. Проверь VM\n",(i+1)*SIZE/1024);
getchar();
}
}
return 0;
}

Тест, слинкованный с "умолчательным" malloc из glibc, отъедает ~8M VM и не отдает ее по free(), т.к. free() делаем с начала кучи: ---------###. Память вернется ОС только после free() последнего куска с хвоста кучи (#)

А с dlmalloc/dlfree, не использующим sbrk() -- __отдает__.

Остается собрать с ним mozilla.

[zov]

Товарищ mr попытался перенести аллокатор из OpenBSD на Gnu/Linux:

http://mr.himki.net/OpenBSD-malloc.c

% gcc -o libmalloc.so -shared OpenBSD-malloc.c
% LD_PRELOAD=./libmalloc.so firefox

Память отдает ядру в ожидаемых количествах.
На старте имеем VM 20M, с ~30 вкладками ~60M, после закрытия всех вкладок, кроме одной, VM возвращается к ~30M.

Как пишет автор переноса, требуется отладка/тестирование.

ЗЫ сейчас пишу из firefox-1.0.6-gtk1, запущенного с openbsd-malloc на ALT Master 2.4