Продолжение: mozilla/firefox и аллокатор из openbsd

В готовом файле: http://mr.himki.net/OpenBSD_malloc_Linux.c

И патчем: http://mr.himki.net/OpenBSD_malloc.patch

Опять же, приглашаются желающие потестировать!

Простейший тест работает. Память возвращается.

#include<stdio.h> #include <stdlib.h>

void *p [1000];

int main (void) { int l, i, align = 16384; srand(1); for (i = 0;i<1000;i++) { l = rand() % 1024*16; posix_memalign(&p[i], align, l); memset(p[i],'c',l); printf("p:%p : p mod align: %d\n", p[i], ((unsigned int)p[i])%align ); if (i%100 == 0 && i) getchar(); } for (i = 0; i < 1000; i ++) { printf("free: p:%p : p mod align: %d\n", p[i], ((unsigned int)p[i])%align ); free(p[i]); if (i%100 == 0 && i) getchar(); } return 0; }

konqueror на ALT Sisyphus свежем все равно сыпет. in free(): error: ifree: junk pointer, too high to make sense.

Тесты из glibc он проходит?

Sorry, форматирование.

Простейший тест работает. Память возвращается.

#include<stdio.h>
#include <stdlib.h>

void *p [1000];

int main (void) {
int l, i, align = 16384;
srand(1);
for (i = 0;i<1000;i++) {
l = rand() % 1024*16;
posix_memalign(&p[i], align, l);
memset(p[i],'c',l);
printf("p:%p : p mod align: %d\n", p[i], ((unsigned int)p[i])%align );
if (i%100 == 0 && i)
getchar();
}
for (i = 0; i < 1000; i ++) {
printf("free: p:%p : p mod align: %d\n", p[i], ((unsigned int)p[i])%align );
free(p[i]);
if (i%100 == 0 && i)
getchar();
}
return 0;
}

konqueror на ALT Sisyphus свежем все равно сыпет.
in free(): error: ifree: junk pointer, too high to make sense.

Тесты из glibc он проходит?

Да с тестами glibc наверняка нормально, не считая realloc(p,0).

У меня и без определения posix_memalign kde 3.3/3.4 нормально работало.

Такая ошибка (ifree: junk pointer, too high to make sense) выводится, когда index > last_index, т.е. возможно пытаемся освободить аллокацию, которая была совершенна не openbsd-malloc. Надо ещё вставить функции valloc и memalign, а также поискать, нет ли ещё других alloc-функций.

>И патчем: http://mr.himki.net/OpenBSD_malloc.patch

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

ну и как недостижимый идеал,
ставить пробелы, типа не 
 u_long end=(u_long)p+(u_long)(pages+alignment)-((u_long)j+(u_long)pages);
а
 u_long end = (u_long)p + (u_long)(pages + alignment) - ((u_long)j + и т.д.,
чтобы можно было что-нибудь понять?

> нет ли ещё других alloc-функций.

`info libc' должна помочь, там есть неплохая глава посвещенная тому каким способом можно получить память.

есть например `cfree':
This function does the same thing as `free'. It's provided for
backward compatibility with SunOS; you should use `free' instead.

* Contents, described in more detail in "description of public routines" below.

  Standard (ANSI/SVID/...)  functions:
    malloc(size_t n);
    calloc(size_t n_elements, size_t element_size);
    free(Void_t* p);
    realloc(Void_t* p, size_t n);
    memalign(size_t alignment, size_t n);
    valloc(size_t n);
    mallinfo()
    mallopt(int parameter_number, int parameter_value)

  Additional functions:
    independent_calloc(size_t n_elements, size_t size, Void_t* chunks[]);
    independent_comalloc(size_t n_elements, size_t sizes[], Void_t* chunks[]);
    pvalloc(size_t n);
    cfree(Void_t* p);
    malloc_trim(size_t pad);
    malloc_usable_size(Void_t* p);
    malloc_stats();

Возможно, надо просто valloc и memalign написать...

>Возможно, надо просто valloc

valloc есть в OpenBSD,
а memalign можно через posix_memalign написать

Положил на прежнем месте файл с valloc и memalign и исправлением одной ошибки. Только, по-видимому, KDE 3.5 у zov'а всё равно не работает...

Ну всё, теперь должно быть правильно. Если kde 3.5 так и не заработает, то даже не знаю, что делать, самому что ли какой-нибудь kubuntu ставить...

Поддерживаю. Нечитабельно.

2mr: Если у тебя все получится, что задумал, то это будет готовая диссертация, а также почет и уважуха! :)

Да, надо конечно всё это дело проверить, разобраться, почему KDE 3.5 у zov'а не работает...

Кстати, люди, у кого ещё KDE 3.5 есть? :)

>Кстати, люди, у кого ещё KDE 3.5 есть? :)

KDE-3.5.3. Варнингов нет, ФФ память отдает.

Скажи, какие тесты погонять, я выложу результаты.

Просто погонять konqueror с этим аллокатором (и проверить, отдаёт ли он память). А ещё лучше -- запустить с ним всю KDE 3.5. Вот собственно и всё. (zov говорит, что у него на altlinix sisyphus не работает вообще ничего из kde 3.5). Спасибо.

Пускал весь KDE, работает без варнингов. Konqueror 37M -> 73M -> 61M. Это не очень хорошо, да?

>Пускал весь KDE, работает без варнингов.

Это очень хорошо, порадовал :)

>Konqueror 37M -> 73M -> 61M. Это не очень хорошо, да?

Это значит, что ты смотришь виртуальную память, которая в линуксе обычно неправильно расчитывается. Да и реальная оперативная память важнее, т.е. то, что показывает top в графе RES. У меня на livecd в KDE 3.4 получались результаты 21M->53M->39M.

Хм, точно, ступил. Поглядел на RES, вот результаты: 21M -> 130M (тут я открыл несколько полутораметровых страничек) -> 33M.

Все еще работаю в KDE с аллокатором, варнингов так и не появилось. Оставлю на пару дней, поюзаю еще :) Спасибо за труд :)

Да, было бы интересно узнать, работает ли наш аллокатор под amd64 ;)

Вот и первая ласточка. При закрытии гимпа ругается gimp in free(): error: chunk is already free и виснет. gimp-2.2.10

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

каким боком она неправильно расчитывается?

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

Там примешивается память от библиотек, и, кстати, говорят, что в rss тоже. Вот, например, ссылка на эту тему (непроверенная), но говорится, что программа только для ядра 2.6.16: http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html

Или вот: http://cvs.gnome.org/viewcvs/white-papers/MemoryUsage/MemoryUsage.txt?rev=1.2

Не настаиваю, что она "неправильно расчитывается", но это факт, что эти данные мало полезны.

>Вот и первая ласточка. При закрытии гимпа ругается gimp in free(): error: chunk is already free и виснет. gimp-2.2.10

Сейчас попробовал gimp 2.2.4, при выходе всё нормально, но, конечно, надо это нормально потестировать... Главная неприятность, что трудно отличить, происходят ли падения по вине аллокатора или по вине самой программы :)

Emacs даже не запустился. Пишет:

emacs in realloc(): error: irealloc: pointer to wrong page Fatal error (6).Aborted

~$ emacs --version GNU Emacs 21.4.1

Сборка Debian.

Аналогично.

$ emacs
emacs in free(): error: free_pages: pointer to wrong page
Fatal error (6)[1]    18836 abort      emacs

GNU Emacs 22.0.50.1

emacs сам не overload'ит ли malloc/free и остальное?

Аналогично:

~% LD_PRELOAD=/home/zov/local/lib/libmalloc.so emacs emacs: (0x853fe68) emacs in free(): error: ifree: junk pointer, too high to make sense Fatal error (6)Aborted

GNU emacs 22.0.50

ALT Linux Sisyphus (20051231)

--------------

vim запускается, firefox-1.5.0.1-gtk1 уже несколько суток работает там же без ошибок.

WBR, zov

ЗЫ KDE 3.5.3 из Sisyphus (20060401) сыпет теми же ошибками.

[andrei@superblin ~]$ LD_PRELOAD=/home/andrei/prog/alloc/malloc.so emacs
irealloc: pointer to wrong page
free_pages: pointer to wrong page
free_pages: pointer to wrong page
emacs: Memory exhausted--use M-x save-some-buffers RET

Про emacs немного непонятно, он ведь на lisp написан, а в lisp вроде должен быть свой менеджер памяти? Как оно там устроено -- не знаю...

А вот с kde что-то странно, непременно надо самому проверить, в ближайшее время устанавлю (может это альтовцы что-то не то накрутили?). И gimp потестировать надо.

> Про emacs немного непонятно, он ведь на lisp написан

Бугогага %))) Издеваешьсо? Вообще-то он на C написан... просто он является "lisp машиной" ;) И _дополнительные_ компоненты написаны на лиспе

Так что тут фих знает что не так...

А если по теме, то мне очень интересен данный "проект" ;) Я тут вчера даже специально поставил оперу (хотя я чесна говоря ненафижу qt/kde, и уж тем более закрытый софт), но! поставил я её только с одной целью - посмотреть как она работает с памятью... что могу сказать... не смотр на всё мою любовь к ФФ, в плане потребления памяти оно сосйот не нагинаясь ;(((((( Почему же ФФ жрёт _ТАК МНОГО ПАМЯТИ_?!?!

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

Удачи!

>Про emacs немного непонятно, он ведь на lisp написан, а в lisp вроде должен быть свой менеджер памяти? Как оно там устроено -- не знаю...

Не, lisp-машина emacs написана на C. Так что где-то что-то не так.

Однако заинтересовался вопросом проверить на работоспособность аллокатора с SBCL, который на 95% (если не больше) написан сам на себе, а маленькая основная часть -- на C. Работает. Не падал.

>Про emacs немного непонятно,

стоит взглянуть на его чудесную emacs-cvs/src/alloc.c

например:

#ifdef DOUG_LEA_MALLOC

#include <malloc.h>
/* malloc.h #defines this as size_t, at least in glibc2.  */
#ifndef __malloc_size_t
#define __malloc_size_t int
#endif

/* Specify maximum number of areas to mmap.  It would be nice to use a
   value that explicitly means "no limit".  */

#define MMAP_MAX_AREAS 100000000

#else /* not DOUG_LEA_MALLOC */

Можно еще иксы через это дело прогнать :)

Хых... как раз этим щас и занимаюсь... 3:45... полёт нормальный... только вот не знаю... как понят - хорошо это или нет :) Ну в смысле, есть ли смысл в этом... ;)

> Сейчас попробовал gimp 2.2.4, при выходе всё нормально

Только что запускал gimp 2.2.6 из Debian Sarge, всё ок... работает, варнингов нет. Пооткрывал, поредактировал несколько фотографий порядка 5-6 мегоф каждая... гимп не падал. При выходе, тоже никаких проблем не было.

> Можно еще иксы через это дело прогнать

Дык именно так в них уже были выявлены ошибки динамич. распределения памяти, под OpenBSD, конечно.

> Дык именно так в них уже были выявлены ошибки динамич. распределения памяти, под OpenBSD, конечно.

Ога... а ещё после перехода с XFree86 4.3 на X.org 6.9 я заметил, что иксы начали дико "течь"... это просто ужос какой-то... через сутки-двое в свопе > 150 метров... стоит только перезагрузить иксы, и там оказыватеся не больше 30... Уж не знаю чего так всё плохо...

Классно, это, как я понимаю, c LD_PRELOAD надо использовать?

А в сообщество мозиллы пробовал обращаться?

Или к разработчикам glibc?

>Классно, это, как я понимаю, c LD_PRELOAD надо использовать?

Да, именно так: http://mr.himki.net/index-alloc.html

>А в сообщество мозиллы пробовал обращаться?

Ещё рано -- пока нет абсолютной уверенности в правильности аллокатора. Хотя firefox с ним нормально работает.

>Или к разработчикам glibc?

Смысла нет. Аллокатор glibc быстрее. OpenBSD-аллокатор полезен только для программ типа firefox.

>Смысла нет. Аллокатор glibc быстрее. OpenBSD-аллокатор полезен только для программ типа firefox.

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

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

>>А в сообщество мозиллы пробовал обращаться?

>Ещё рано -- пока нет абсолютной уверенности в правильности аллокатора. Хотя firefox с ним нормально работает.

Хм, я думаю на ночь оставить, обычно у меня к утру практически вся память файрфоксом оказывается съедена, правда может дело в самих утечках, в огнелисе.

А обратиться с целью узнать, предпринимают они какие-либо действия по этому поводу, вроде в багтраке у них я видел сообщения об такой фигне.

>>Или к разработчикам glibc?

>Смысла нет. Аллокатор glibc быстрее. OpenBSD-аллокатор полезен только для программ типа firefox.

Может имеет смысл держать несколько аллокаторов в главной библиотеке, и выбирать нужный на этапе компоновки?

> Мне кажется, что смысл какой-то заявить о себе в glibc-листах есть. Пусть пообсуждают хотя бы. Может, мысли какие-то интересные будут.

100% согласен.

>Быстрее или не быстрее, но разницу в скорости работы с обычным аллокатором и твоим я что-то особо не заметил

А на многпроцессорных машинах разница может быть заметна. Сейчас и "десктопные" процесссоры многоядерными бывают.

>Сейчас настало время жрущих приложений (иксы, фаирфокс и мн. др).

Но все как-то с проблеммой справляются. Теми же пулами в apache.

>Пусть пообсуждают хотя бы.

Э-эх. Так ведь даже опционально его не включить -- он на BSD-лицензии. Да и примитивный он, этот openbsd-аллокатор, откровенно говоря. Для openbsd сходит, а для линукса мелковато... Так что надо бы новый, хороший аллокатор писать -- только кто это будет делать? :-/

> Э-эх. Так ведь даже опционально его не включить -- он на BSD-лицензии.

Хех, а внутри написано Beer-ware ;-)

> Да и примитивный он, этот openbsd-аллокатор, откровенно говоря. Для openbsd сходит, а для линукса мелковато... Так что надо бы новый, хороший аллокатор писать -- только кто это будет делать? :-/

Может mr?

>хотя априори известно, что mmap медленнее.

Я всё время думал, почему бы не сделать так же, как openbsd'шники, но выделять/освобождать память не через mmap/munmap, а с помощью sbrk/madvise? Если это действительно mmap виноват (что вообще-то надо проверить), то это поправило бы скорость. И переделать таким образом openbsd-аллокатор должно было быть не сложно...