Почти все современные браузеры страдают от утечек памяти (кроме IE9, Opera)

Вот уже который год разработчики браузеров не могут устранить проблемы с утечками памяти. Например, больше года назад этот баг репортили для Chromium (#36142), но до сих пор ситуация не сдвинулась с мёртвой точки. Аналогичные репорты подавались в Bugzilla давным-давно.

Очередной этап этой бесконечной эпопеи — новый пример очень больших утечек памяти (#81517 для Chromium). Он отличается #36142, поскольку здесь зафиксированы утечки без использования кэша, а методом многократной загрузки одного изображения в оперативную память с атрибутом NO-STORE.

Поскольку браузер не освобождает память до закрытия документа, то в течение нескольких минут картинка JPEG размером 22 КБ приводит к полному исчерпанию любого количества RAM и обрушению браузера. Баг подтверждён для Chromium 11.0.696.60, Safari 5 и Firefox 4.x. Уязвимость распространяется на все браузеры на движке WebKit.

Семейство IE 7/8/9 и Opera 11.10 прошли тест успешно. Интересно, что в IE9 этот баг тоже присутствовал, но его быстро исправили.

Говорят, что Firefox 3.6 и Firefox 6.0a1 тоже проходят тест. Остальные версии нужно ещё проверять. Тест находится по адресу memleakbug.appspot.com/.
–1
19 мая 2011, 12:32
2
alizar 2275,0 G+

комментарии (31)

0
homm #
И?
0
socialNoob #
> не освобождает память до закрытия документа — вполне правомерное и обоснованное поведение в случае
браузера, где каждая вкладка — отдельный процесс.

Тест синтетический и провокационный. Это все равно что положить перед ребенком конфету и сказать «не ешь!», и каждые пол секунды добавлять еще конфетку.

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

Кстати, в защиту хрома хотелось бы сказать, что отвалилась только вкладка с неугодным скриптом.

Поэтому этот баг скорее не критический, а минор средней важности, поэтому никто и не бежит сломя голову его править.

–2
homm #
Вообще-то вы ошибаетесь и новых конфет там не кладут, а заменяют одну на другую. Т.е. в один и тот же элемент грузят новые картинки, при этом ссылок на старые не остается и их стоило бы освобождать.
+1
VolCh #
Увы, но в Хромиуме (и, видимо, в Хроме) не каждая вкладка отдельный процесс — вот у меня сейчас один процесс на эту вкладку и ещё 11.
–4
Kirhgoff #
В Хроме каждая вкладка — отдельный процесс, только что посмотрел в Таск Менеджере, версия 11.0.696.60 unknown
0
VolCh #
В хромиуме так, насколько я понял, только пока вкладок <6. Когда их число >30, то процессов с --type=renderer всё равно 5. Смотрел через htop.

+2
Kirhgoff #
А откуда цифра 30? Я вот нашел доку по их процессной модели

www.chromium.org/developers/design-documents/process-models

По умолчанию используется Process-per-site-instance — то бишь каждая вкладка — это отдельный процесс, только когда они открывают странички с разных сайтов. Если открыть сотню страничек на хабр, рендерится они будут одним процессом.

Но я в любом случае был неправ, каюсь.
0
VolCh #
Просто прикинул число открытых у себя вкладок :)

Но вот с per-site как-то тоже не вяжется — прямо сейчас две группы вкладок с хабром разбиты на два процесса, в каждом есть и другие сайты (правда все они открыты или с линков на хабре, или с поиска в адресной строке «поверх» habrahabr.ru/… с последующим alt+enter).

Хотя, может быть, настройки у меня не дефолтные, ставлю с пакетов
+2
Devgru #
Вы заслужили ссылку на это видео :)
www.youtube.com/watch?v=sgflnxYYPUc
+3
easyman #
К сайту, демонстрирующиму уязвимость пришел хабраэффект.
–2
Zerstoren #
Если б оно стояло не на Гугл Апп, а на вирт хостинге, то хабраэффект и вирт хостинг положил бы
–5
zCooler #
Даже гугл не выдержал хабраэффекта :D
+3
igrishaev #
Квоты кончились, вот и всё.
+11
mihaild #
Уточнение: хабраэффекта не выдержали финансы автора теста:)
+2
AHDPEu #
Самая главная утечка — фаербаг, вот я бы счастлив был — не перегружать постоянно лису
0
ad_Wolf #
Просто одни больше, другие меньше.
+4
Kicker #
Читаю заголовок и мозг уже сам подставляет окончание (:
«Почти все современные браузеры страдают от утечек памяти, alizar»
0
Dreddik #
Работал я как-то с QWebView (из QT), на платформе Symbian. Если в него грузить картинки, то у телефона память кончается на 5-7 картинке.
Так что можно утверждать, что все браузеры страдают от утечек памяти.
Но тут нечему удивляться, ведь писали эти вещи люди, они имеют право на ошибки
0
d3ot #
> Почти все современные браузеры страдают от утечек памяти

Ага. А старые значить в своё время не страдали?
0
alizar #
В FF 3.6 этого бага вроде нет.
0
Rihtor #
Это точно. Сафари на маке сжирает гиг оперативы враз!
+4
anreyyyy #
Без паники! Проблема решается установкой 64x-bit ОС + 6 гигов оперативы. Проверил на себе.
0
VolCh #
И можно месяц браузер не рестартовать?
0
anreyyyy #
Месяц не знаю — но неделю в легкую.

У меня постоянно запущен хром (10+ закладок), firefox, opera, photoshop.
Иногда IE и мелкий софт. Комп не выключаю.

Занято памяти 3-4 гига. Все летает, ниче не падает, не тормозит. Жизнь прекрасна!
0
VolCh #
Попробовать что ли своп увеличить до 6 гигов :)
0
magnum #
если винч шустрый — пробуй. если нет -то лагать будет аццки
0
odyvan #
Ну, я также починил проблему на маке — купив 8Gb (благо
–2
reiser #
А зачем 64бит? PAE чем не устраивает?
+6
anreyyyy #
Костыль
0
magnum #
вот отстой :(
у меня 64 ОС, но 4гб максимум что можно впихнуть
0
hooey #
Ха, я еще в 2004 году жаловался на linux.org.ru на то, что у меня Firebird/Firefox ест гигабайт памяти (а у меня тогда всего гигабайт было), даже если не открыта ни одна вкладка. Меня обсмеяли и сказали, что я гоню.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.