Фрагментация памяти в FireFox (?) и как бороться

>А можно подробнее (или ссылку)?

Боюсь, что нет, сам бы хотел почитать. Если у меня и есть на уме какие-то алгоритмы, то разве что придуманные мной самим. А как работает openbsd аллокатор, я не изучил, на него кажись доков нету и комментариев в коде совсем мало :(

2mr:

Вот, собственно, ты все сам и раскопал!

Может, стОит подумать, как с этим можно бороться...

Тогда нужно тестирование аллокатора. Поскольку основное подозрение теперь падает не на сам аллокатор, а на gtk, прежде всего glib, то надо выводить версии glib/gtk.

То, что стоит на моём текущем компьютере -- это libglib2.0_0-2.11.1-1mdv2007.0 и libgtk+2.0_0-2.8.11-1mdk.

Я проверил на втором своём компьютере, и кажется, теперь всё понятно.

Там стоят glib 2.8.3 и glib 2.9.6-1, причём .so последней были установленны в /usr/local/lib/. И в конфиге shell'а у меня стоял export LD_LIBRARY_PATH=/usr/local/lib. (Теперь понятно, почему и на этом компьютере были ворнинги). Я запомнил сеанс firefox, в котором всегда воспроизводятся ворнинги -- так вот, после комментирования той самой строчки и перезапуска shell (т.е. когда libglib-2.0.so берётся из обычного каталога, т.е. версии 2.8.3) воспроизвести ворнинги не удаётся! Я повторил это (комментирование и раскомментирование) несколько раз и надёжно в этом убедился.

Итак, сомнений в моём случае теперь нет -- ворнинги вызываются ошибочной glib.

Версия 2.8.3 работает, похоже, правильно.

glib 2.10.3, amd64, при попытке с твоим аллокатором закрыть в таб в firefox'е, оный повис. :(

ALT Sisyphus 01.04.2006:

glib2-2.10.3, libgtk+2-2.8.18 (ALT Sisyphus 01.04.2006)-- есть warnings, mozilla не работает, программы, использующие только glibc -- работают там же. Там же: kdelibs-3.5.3 -- ничего из КДЕ не работает.

У zov работало без warnings с gtk+-1.2.10 + glib-1.2.10, gtk+2-2.4.14 + glib2-2.4.8 (ALT Master 2.4),

kde работал в slackware 10.2 без warnings вообще.

Возможно, openbsd-malloc можно использовать для ловли ошибок в программах. Утверждалось, что использование аллокатора OpenBSD позволило поймать ошибки в XFree86/X.org, ссылку на вскидку не приведу.

WBR,

zov

>kdelibs-3.5.3 -- ничего из КДЕ не работает.

Блин, как не хорошо. У меня и kde 3.3.2, и kde 3.4 в Mdv1 работали сами по себе без ворнингов. Неужели в 3.5 всё поломали?

Вот тут чего-то есть для обсуждения.

http://bluefoxicy.blogspot.com/2004/05/mixed-memory-allocatora-hybrid.html

>Тогда нужно тестирование аллокатора. Поскольку основное подозрение теперь падает не на сам аллокатор, а на gtk, прежде всего glib, то надо выводить версии glib/gtk.

В последних glib появилась есть такая хрень по эффектиквной работе с памятью GSlice. Может, какие-то конфликты в этой части?

Я когда смотрел gslice, вообще не понял, что это вообще такое. Надстройка над обычным malloc какая-то. Что именно она делает -- непонятно.

Даже не понятно, как она используется в других функциях glib. Кстати, у меня при запуске k3b (!) падает с такой ошибкой (с обычным аллокатором, конечно):

***MEMORY-ERROR***: [29731]: GSlice: failed to allocate 248 bytes (alignment: 256): Invalid argument

Откуда это берётся, непонятно. В общем, с этой хренью ещё надо разобраться.

>>Тогда нужно тестирование аллокатора. Поскольку основное подозрение теперь падает не на сам аллокатор, а на gtk, прежде всего glib, то надо выводить версии glib/gtk.

>В последних glib появилась есть такая хрень по эффектиквной работе с памятью GSlice. Может, какие-то конфликты в этой части?

Вот, похоже, вся инфа, что есть по этой хрени: http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slices.html

>Я когда смотрел gslice, вообще не понял, что это вообще такое. Надстройка над обычным malloc какая-то. Что именно она делает -- непонятно.

Могу дать только примерное направление, где искать. Я вскользь поинтересовался этим gslice, когда вышел обзор Gnome 2.14 (вот этот обзор. См. заголовок GSlice). Знаю, что этот механизм они применили и в части отображения шрифтов, так как получили якобы значительное ускоерние при выделении одинаковых по размеру участков памяти (что это значит, я пока не осознаю). Насколько я понимаю, это не совсем обвязка вокруг malloc. Там есть переменная окружения G_SLICE, котрую если установить в always-malloc, то gslice становится обвязкой к malloc, а если не установлена, то он работает не с malloc, а самостоятельно. Но все это проверять надо -- я за слова не отвечаю. Просто что-то где-то видел. :)

Вот тут для девелоперов написано что-то.

http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slices.html

>Вот, похоже, вся инфа, что есть по этой хрени:

Да-да :) И я одновременно поискал :)

Ой, торопился. Забыл ссылку на обзор гнома дать:

http://www.gnome.org/start/2.14/notes/ru/rndevelopers.html

ФФ он и под виндой памяти кушает немеряно и не отдает. Ваша версия о плохом аллокаторе памяти glibc и(или) ошибке связанной с glib как совмещается с одинаковыми проблемами памяти на двух платформах ?

А, т.е. оно используется только для маленьких переменных. Когда я смотрел, у меня получалось, что оно работает как обычный malloc (результат освобождения, напр., зависел от MALLOC_MMAP_THRESHOLD_), но я смотрел для больших аллокаций...

В любом случае, этот gslice просто не имеет права быть привязанным к конкретному аллокатору, glibc malloc. Значит, надо проверить его и если окажется, что это он виноват, то слать bugreport разработчикам glib.

Просто может быть, что в новых версиях glib что-то другое неправильно работает, хотя именно на gslice основное подозрение...

Под какой именно вендой? У них у всех библиотеки разные. zov говорил, что под windows 2003 server память firefox отдаёт хорошо. Я проверял на windows-xp-sp2, там firefox память отдаёт, но не очень хорошо.

судя по описанию slice использует POSIX_MEMALIGN(3),
также на той же man page странице перечислены
valloc
и
memalign

и они реализованы в glibc, а потом указатель на такие блоки отдают
free из openbsd-malloc.so и получается....

ЗЫ

я думаю надо и эти функции взять из openbsd

Дня три погонял систему с export LD_PRELOAD=malloc.so в основном профиле. Серьёзных проблем не заметил: только периодические pagefree_pages: pointer to wrong да ещё какой-то сбой kdeinit при загрузке KDE, но вроде все остальные программы работают.

glib2 2.11.3
gtk2 2.8.19

>я думаю надо и эти функции взять из openbsd

Да, возможно, что это не из-за ошибки в glib, надо попробовать!

>Да, возможно, что это не из-за ошибки в glib, надо попробовать!

только есть маленькая такая проблема:
x86-openbsd1:~$ man memalign
man: no entry for memalign in the manual.
x86-openbsd1:~$ man posix_memalign
man: no entry for posix_memalign in the manual.
x86-openbsd1:~$ uname -a
OpenBSD ... 3.8 GENERIC#138 i386

valloc есть конечно, но...

Да, этот вопрос требует тщательного разбирательства...

> zov говорил, что под windows 2003 server память firefox отдаёт хорошо.

Под windows 2000, windows 2000 + SP4 отдает. Windows 2003 не проверял.

wbr,

zov

А, точно.

Кстати, интересен также аллокатор из FreeBSD: http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb.cgi/~checkout~/src/lib/libc... Было бы не плохо, если бы кто-нибудь, имеющий FreeBSD под рукой, скомпилировал бы там этот аллокатор без USE_BRK и сказал результат (тестирования firefox).

Сейчас это windows 2003 server. Я не знаю, что было у других, но у меня он одно время больше полугига спокойно отжирал и не отдавал. В основном проблены начинаются когда открываешь новой окно, в то время, когда в старом уже открыто много вкладок. Так же ФФ себя вел и под ХР.

Сейчас я немного поменял его поведение через confi.trim_on_minimize, но все равно память не отдает.

fghj:

>slice использует POSIX_MEMALIGN(3), ... потом указатель на такие блоки отдают free из openbsd-malloc.so и получается...

Да, посмотрел на исходники glibc, так и есть.

Даже если выравнивание достаточно мало, когда все эти функции просто зовут malloc(), они его зовут внутренним именем.

Действительно, posix_memalign виноват.

Написал затравочную функцию posix_memalign и вставил её в OpenBSD-malloc.c:

int posix_memalign(void **memptr, size_t alignment, size_t size) { void *p = malloc(alignment+size-1); size_t shift = ((size_t)p+(size_t)alignment) % (size_t)alignment; *memptr=(void*)((size_t)p+shift); }

Всё заработало без ворнингов!

int posix_memalign(void **memptr, size_t alignment, size_t size)
{
    void *p = malloc(alignment+size-1);
    size_t shift = ((size_t)p+(size_t)alignment) % (size_t)alignment;
    *memptr=(void*)((size_t)p+shift);
}

Два size_t лишние, конечно:

int posix_memalign(void **memptr, size_t alignment, size_t size)
{
    void *p = malloc(alignment+size-1);
    size_t shift = ((size_t)p+alignment) % alignment;
    *memptr=(void*)((size_t)p+shift);
}

> *memptr=(void*)((size_t)p+shift);

а когда ее захотят осводить,
получем ситуацию похожую на:

free(malloc(10)+3);

думаешь open bsd да и любой другой аллокатор не сломается от этого?

в общем получается чтобы помочь пользователям
linux, надо сначала помочь пользователям *BSD и реализовать
posix_memalign.

ЗЫ

граница выравнивается не только по alingment, но и по sizeof(void *)

Кстати, возможно, именно в выравнивании дело!

ГНУтый же маллок на 8 равняет!

Как "твой" маллок поступает?

Стоп. Под *BSD KDE 3.5.* и свежие glib2, gtk2 есть? Тогда проще посмотреть на патчи, которые в OpenBSD применяются при сборке KDE/glib/gtk из портов. Недостающие в OpenBSD ф-ции в патчах реализованы скорее всего.

wbr,

zov

>Стоп. Под *BSD KDE 3.5.* и свежие glib2, gtk2 есть? Тогда проще посмотреть на патчи, которые в OpenBSD применяются при сборке KDE/glib/gtk из портов. Недостающие в OpenBSD ф-ции в патчах реализованы скорее всего.

Это хуже, потому что тогда придется пачить все эти библиотеки. Лучше уж добивать glibc недостающим, ИМХО.

Так ведь не ломается -- может он и при попадании free в середину куска правильно освобождает? Хотя вообще не спорю, этот posix_memalign чисто затравочный, надо писать настоящий.

>ГНУтый же маллок на 8 равняет! Как "твой" маллок поступает?

16

Глядя на исходники, сходу про выравнивание не понятно. Типа, написано, что 16 байт, но как-то не совсем понятно...

Попробуй посмотри эксперименрально. Если возвращаемый адрес не кратен 8, то попробуй выровнять в imalloc() size на 8, наверное, поможет...

Да, похоже именно на 8 выравнивает.

>Так ведь не ломается -- может он и при попадании free в середину куска >правильно освобождает?

скорее объяснение состоит в том, что в случае glibc posix_malloc адресс был совршенно левый и реализация смогла это отследить, а вот в варианте когда уже собственный malloc используется,
проверка на дурака не работает, и как при этом ломаются внутринние структуры
один черт знает.

ЗЫ

может вынести обсуждение в список рассылки OpenBSD,
возможно уже есть готовая реализация? google правда ее не находит.

Еще идея.

По моему опыту, основные механизмы разрушения кучи -- когда с массивом на 1 лопухнулись, и перетерся заголовок следующего свободного чанка в пуле.

Можно попробовать распределять на 16 байт больше, и отдавать со смещеним в 8 байт, чтобы концы подстраховать (соответственно, free освобождает адрес-8). Если падения прекратятся, то все ясно...

>огда проще посмотреть на патчи, которые в OpenBSD применяются при сборке >KDE/glib/gtk из портов.

какие-то накладывают, но это не имеет отношение к posix_memalign,
configure glib проверяет есть ли эта функция, и если дана собирается
одна часть кода, если нет другая(она использует valloc в случае *BSD).

Пересобирать всю систему это не метод.

>может вынести обсуждение в список рассылки OpenBSD,
возможно уже есть готовая реализация? google правда ее не находит.

Уже писали одному из разработчиков, по имени Otto Moerbeek:

>>Dear Mr. Moerbeek,
>> 
>> I wonder if I could ask you a question about the OpenBSD memory allocator.
>> It is not a secret that OpenBSD allocator is good for such programs as
>> firefox.
>> Unfortunately my main work system is Linux.
>> Is there a version of this allocator for Linux OS? (or may be you know about
>> other similar allocators existing on this OS?)
>> 
>> Thank you in advance.


There's no version for Linux. Also, we very much depend on the
randomization features in the mmap(2) system call.

	-Otto

>Если падения прекратятся, то все ясно...

Так вроде с той posix_memalign с firefox нет никаких ворнингов и сам firefox на вид работает нормально. А если ты имеешь ввиду то, что kde 3.5 не работает, то это не понятно почему. В общем, ещё надо потестировать...

>Уже писали одному из разработчиков, по имени Otto Moerbeek:

возможно возникло недопонимание, я не имел ввиду портирование,
моя враза относилась к posix_memalign,
я имел ввиду реализация posix_memalign для OpenBSD,
судя по всему в cvs ее нет.

s/враза/фраза/g

их собственная реализация valloc весьма похожа


void *
valloc(size_t i)
{
long valsiz = getpagesize(), j;
void *cp = malloc(i + (valsiz-1));

j = ((long)cp + (valsiz-1)) &~ (valsiz-1);
return ((void *)j);
}

Кстати, сейчас убедился, что тыкать free() в середину куска нелья и в openbsd-malloc. Интересно, почему тогда с такой функцией оно работает :)

А posix_memalign, похоже, прийдётся писать своими силами. Хотя, может, они сами её скоро напишут? :)