LINUX.ORG.RU

Firefox 2.0.0.1, Firefox и Thunderbird 1.5.0.9


0

0

Вышло сразу три обновления продуктов Mozilla Corporation: как ветки 2.0 браузера Firefox, так и ветки 1.5 его и почтового клиента Thunderbird.

Замечания к релизам:

Firefox 2.0.0.1 (исправлено 8 уязвимостей, улучшена совместимость с Vista): http://www.mozilla.com/en-US/firefox/...
Firefox 1.5.0.9 (исправлено 7 уязвимостей): http://www.mozilla.com/en-US/firefox/...
Thunderbird 1.5.0.9 (исправлено 7 уязвимостей): http://www.mozilla.com/en-US/thunderb...

>>> Скачать

★★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

>> <вытащил значок "Заслуженный провокатор"> > Про прогресс с фрагментацией памяти тоже интересно узнать. > </убрал значок>

>А что это такое?

Это хорошо известный эффект: фрагментация кучи (arena), используемой ф-циями *alloc(), free().

В glibc, при запросе malloc(size) c size < MMAP_THRESHOLD(=128K) либо находится свободный chunk размером >size в середине кучи, или -- если нет подходящего свободного chunk'а -- вызывается sbrk() для "подъема" вершины кучи. В результате последующих вызовов free() и/или realloc() куча приобретает вид вроде

[#----#-#-------##]

'#' обозначает занятый chunk, '-' -- свободный, например, после free().

Так как для расширения кучи использовался только sbrk(), то свободные страницы процесс может вернуть ядру только вызовом sbrk(-размер), если страницы находятся на вершине кучи. Свободные страницы из середины кучи вернуть ядру не можем.

Браузер в среднем запрашивает куски << MMAP_THRESHOLD, а потом освобождает их, вообще говоря, не в строго обратной последовательности (т.е. последним запросили -- первым освободили). Поэтому размер VM браузера в среднем растет в течение сеанса. Например, после закрытия нескольких вкладок, VM не может уменьшится на ожидаемую величину, потому что free(p) вызывались c 'p' в середине кучи, а на вершине кучи остался неосвобожденный кусок. После этого, вызов malloc(size) c size > размера любого свободного chunk'а в куче, но c size < MMAP_THRESHOLD приводит к вызову sbrk. Куча опять растет.

В результате, даже при _отключенных кэшах_ после открытия/закрытия нескольких страниц размер VM с единственной оставшейся вкладкой about:blank может быть >> размера VM при старте браузера с about:blank.

См., например, https://bugzilla.mozilla.org/show_bug.cgi?id=324081#c17 и далее по тексту.

Проблема частично решается заменой "аллокатора памяти" glibc на "аллокатор" из libc OpenBSD, который использует _только_ mmap/munmap для создания/возврата многих мелких куч.

См., например, http://mr.himki.net/OpenBSD_malloc_Linux.c -- OpenBSD-аллокатор, перенесенный на Linux; компилируется в *.so. Автор переноса пишет сюда под ником mr, если здесь появится, объяснит лучше, чем выше.

Или можно вписать OpenBSD-аллокатор в исходники mozilla: http://polar.ihep.su:8002/mozilla_malloc_linux-patch.gz

Для проверки возврата памяти простой пример: http://www.linux.org.ru/jump-message.jsp?msgid=1689488#1693013

Мои извинения за много букв.

z11780
()
Ответ на: комментарий от z11780

P.S. Конечно: от фрагментации куч mmap-based allocator полностью не лечит.

Но с ним VM, например, после закрытия нескольких вкладок уменьшается на величину, близкую к ожидаемой.

z11780
()
Ответ на: комментарий от z11780

>Это для gtk2 специфично?

Видимо да. В эклипсе такая же фигня :(

anonymous
()
Ответ на: комментарий от funny_falcon

> Ищи "Russian hot keys bugfix".Работает на ура.

А если кроме английской и русской раскладок я пользуюсь ещё и третьей?

bbk123 ★★★★★
()
Ответ на: комментарий от bbk123

> А если кроме английской и русской раскладок я пользуюсь ещё и третьей?

Перделки на такое не рассчитываются :)

anonymous
()

помимо всем надоедливого рашин хоткей бага, уже пару лет наблюдаю такой баг:

если открыть firefox в качестве файл менеджера (file:///), то он так не может зайти в директорию где лежит файл более 2 гигабайт.

как уже достала жуткая пассивность этой корпорации (mozilla.com), зарабатывают миллионы баксов, а нихрена не могут пропатчить многолетние баги (пустяковые)

jedy ★★
()

Внимание!

2.0.0.2 это начальный шаг к переходу на другую систему нумерации Фаерфокса.

Ждите следующую версию FireFox 2007.

Socrat_
()
Ответ на: комментарий от jedy

> как уже достала жуткая пассивность этой корпорации (mozilla.com), зарабатывают миллионы баксов, а нихрена не могут пропатчить многолетние баги (пустяковые)

У них этих багов выше крыши, причём есть и далеко не пустяковые. Сейчас им надо доводить до ума Gecko 1.9/Firefox 3. Работа кипит вовсю, в этом могу уверить, хоть и не разработчик.

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

Кстати, зарабатывает Мозилла копейки по сравнению с другими корпорациями подобного масштаба. Причём понятно, почему. И те деньги, которые не идут на зарплату сотрудникам, идут в благотворительный фонд.

Sikon ★★★
() автор топика
Ответ на: комментарий от Sikon

А вообще, неужели никто сторонний эти вещи не патчил? Неужели нету патчей на многолетние баги для мозиллы?

jedy ★★
()
Ответ на: комментарий от Relan

> Если кто-нибудь, имеющий опыт написания расширений под Тундыбырд, подскажет куда копать

XPI в почте + есть вопрос один; лучше мылом.

br, mash

anonymous
()

кстати помимо этого обновился и Seamonkey

jedy ★★
()
Ответ на: комментарий от jedy

Я не понимаю: если есть костыль, да ещё выложен на сайте как расширение, -- неужели разработчики не могут использовать его для того, чтобы облегчить себе исправление ошибки? Кстати, при установке этой заплатки у меня перестали работать горячие клавиши в латинской раскладке. И ещё такое: "фокс" через несколько часов работы начинает жрать память и уходить в своп. Если он работает больше суток, то достаёт себя из свопа несколько минут. И это тоже их проблема, о которой постоянно твердят на форуме. Но отношение к пользователям явно наплевательское. Меня это уже достало, поэтому я перешла на "Оперу", благо там появился виджет "Gmail checker". Собственно говоря, именно "Gmail manager" удерживал от перехода на "Оперу". Теперь наслаждаюсь отличной реализацией закрытого браузера. А "ТорМозилла" явно клепает релизы по принципу "работает -- и ладно". А как работает -- это их уже не волнует.

anonymous
()
Ответ на: комментарий от anonymous

> И ещё такое: "фокс" через несколько часов работы начинает жрать память и уходить в своп. Если он работает больше суток, то достаёт себя из свопа несколько минут. И это тоже их проблема, о которой постоянно твердят на форуме.

Это проблема glibc, а не Firefox.

http://mr.himki.net/OpenBSD_malloc_Linux.c

http://polar.ihep.su:8002/mozilla_malloc_linux-patch.gz

z11780
()
Ответ на: комментарий от Gharik

Ага, оно рулез, вот только кто бы просветил, как links с locale=ru_RU.UTF-8 подружить, цены б ему не было...

Kuzmich ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.