В Firefox 3 будет решена проблема с утечками памяти
Пользователи браузера Firefox наверняка знают его самый большой недостаток, который не могут решить уже больше года — утечки памяти. Cо всеми открытыми табами и графическими изображениями в памяти иногда браузер «съедает» до 200 МБ RAM. Самое печальное, что эта проблема не решена даже во второй версии Firefox (кодовое название Bon Echo), которая сейчас находится в стадии бета-тестирования.

Но мало кто знает, что параллельно с Firefox 2 идет разработка следующей версии браузера Firefox 3.0 под кодовым названием Minefield, которая появится в течение 2007 г. Так вот, даже в альфа-версии этот браузер никогда не занимает больше 70 МБ в памяти, даже с десятком открытых табов. Можно скачать, например, дистрибутив под Windows (файл 5,8 МБ) и проверить это самостоятельно.

После заметки о Peppy я почти обрадовался — вот оно, счастье. Наконец появился движок CSS-селекторов, который делает тоже самое, что и jQuery, только быстрее. Сильно быстрее.

Радоваться было недолго, как только я посмотрел в код, то немного ужаснулся: он не соответствовал моим представлениям об исключительной производительности. Совсем не соответствовал. Точнее, немного удовлетворял, но не до конца. Поэтому сразу встал вопрос: а если быстрее?

Почему нельзя сделать быстрое мини-ядро для CSS-селекторов, которое обеспечит базовую функциональность для работы с DOM (ну, совсем базовую — просто выборку элементов, например)? И, самое главное, чтобы это работало не медленнее (в идеале, даже быстрее), чем нативные вызовы.

Февральская встреча состоится 20 февраля 13:00-15:00 в "Избе-читальне" на Артема 110. В программе:

• Александр Шишкин: Об утечках памяти
• Александр Литовченко: Преферанс на Python
  Его пост об этом появился на Хабре
• Артем Дударев: Пара слов о Jekyll

В этом году встречи проходят каждую третью субботу месяца. Следите за группой:
groups.google.com/group/cnc-donetsk

В DevExpress мы тратим много сил на бизнес компоненты для WPF и Silverlight. У нас есть своя линейка контролов, в список которых недавно вошел DXPivotGrid – замена инструмента PivotTable из Excel. В процессе разработки новых компонентов, мы стараемся по-максимуму использовать существующий код. Например, базовые классы от версии PivotGrid для WinForms. Часто это рождает проблемы, с которыми ты не сталкивался, разрабатывая под .NET 2.0. Когда я писал PivotGrid для WPF, мне пришлось решить проблемы с утечками памяти из-за подписки (точнее, «неотписки») на события.

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

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

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

А если вам просто понравилась девушка с картинки, то здесь хайрез :)

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

Однажды в одном большом-большом городе, в одной большой-большой ИТ-компании тестировали один большой-большой проект в одном очень используемом браузере. И обнаружили там утечки памяти. Большие-большие. Прям незадолго до релиза.

И было бы это неудивительно, если бы разработчики были совсем глупые. Но нет же, разработчики наизусть знали «Understanding and Solving Internet Explorer Leak Patterns». Циклические ссылки разрывали, замыкания не использовали, к событиям относились с должным почтением и удалять обработчики не забывали. Да вот только от утечек это не спасло.

Винни Пух: Ой, что это случилось с твоим хвостом?
Иа: А что с ним могло случится?
Винни Пух: Его нет.
Иа: Ты не ошибся?
Винни Пух: Хвост или есть или нет совсем! Тут нельзя ошибиться.
Иа: А что же тогда там есть?
Винни Пух: Ничего!

У нас в проекте, в одном из серверных компонентов, после очередного рефакторинга начала течь память. Казалось бы .NET, F#, менеджед код, сборка мусора, все дела, но память, куда-то утекала. Ценой бессонных ночей и попорченных нервов, источник утечки был найден. Оказалось что проблема вызвана куском кода, который был, чуть ли не один к одному скопирован из учебника по F#.

Все дело было в хвостовой рекурсии, вернее, как оказалось в ее отсутствии в неожиданных местах.

Цитата из Google JavaScript style guide:

Возможность создавать замыкания — похоже, самая полезная и часто остающаяся без внимания особенность JS.

Однако, одну вещь нужно иметь виду: замыкание хранит указатель на замыкаемый им контекст. В результате, прикрепление замыкания к элементу DOM может породить циклическую зависимость и, следовательно, утечку памяти. Например, в следующем куске кода:

function foo(element, a, b) {
  element.onclick = function() { /* использует a и b */ };
}

замыкание хранит указатель на element, a и b даже в том случае, если оно никогда element не использует. А раз element тоже хранит указатель на замыкание, то получается цикл, который никогда не будет вычищен сборщиком мусора.

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

delete testedObject[ i ].obj;

Но, повторюсь только в определенных условиях. Еще одно но, пока точно неизвестно это браузерный баг или особенность JS.
Гугл, ничего не сказал мне по этому поводу, Копания в спецификации ECMAScript, тоже ничего не дало, ибо ее трудно понимать в трезвом состоянии. Собственно это и стало поводом написания данной статьи.

Пост про эрланг, но применим и ко всем другим языкам.

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

В erlang есть три интересующих нас функции: timer:send_interval, timer:send_after и erlang:send_after.

Сначала объясню, почему нельзя пользоваться send_interval.

От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Cocos2d-x — это «движок», а точнее — набор классов, который сильно упрощает разработку графических приложений для операционных систем таких как iOS, Android, Windows phone, Windows, а также для HTML 5. В отличии от сocos2d-iphone, cocos2d-x предполагает разработку на C++, поэтому он такой универсальный. Те, кто пишет на C++ знают, что вся ответственность за выделение и освобождение памяти лежит на плечах программиста. Но разработчики cocos2d-x не плохо позаботились об этом и встроили в свой замечательный движок пул объектов, который предполагает использование смарт-поинтеров или, другими словами, умных указателей.

В этом посте я хочу обобщить и поделится полученным опытом при разработке библиотеки node-queue-lib. Я расскажу о технологиях, которые помогли мне довести дело до финального конца — работоспособного кода, который уже работает на одном из моих сервисов. Особенностью данной библиотеки является кросс-платформенный клиент, т.е. клиент работающий в node.js и браузере и основан на одном и том же коде. В посте будут описаны следующие инструменты, без которых разработка этой библиотеки превратилась бы в ад:

• Тестирование (jasmine_node)
• Покрытие кода тестами (istanbul)
• Сборка клиенткой части библиотеки (browserify)
• Автоматизированное тестирование клиента (phantomjs)
• Поиск утечек памяти (memwatch)

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

И дополнительно, повторю, что статья обзорная, и не ставит целью научить Вас виртуозно пользоваться всеми перечисленными инструментами. Я лишь покажу дверь, но откроете Вы её сами…

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


Конечная цель этой статьи — ответ на простой вопрос:
Куда нажать, чтобы узнать, какую строчку в приложении поправить?

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

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

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

Нас часто спрашивают, умеет ли статический анализатор кода PVS-Studio выявлять утечки памяти (memory leaks). Чтобы много раз не писать похожие тексты в письмах, мы решили дать подробный ответ в блоге. Да, PVS-Studio умеет выявлять утечки памяти и других ресурсов. Для этого в PVS-Studio реализовано несколько диагностик и в статье будут продемонстрированы примеры обнаружения ошибок в реальных проектах.

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

Массивная утечка памяти веб-сервисов и систем безопасности компании Cloudflare может раскрыть пользовательские данные тысяч сайтов. Другими словами: пришло время сменить свои пароли.

Еще много предстоит узнать о масштабах возможного вреда этой утечки, которую уже прозвали Cloudbleed – по аналогии с Heartbleed имевшей место еще в 2014 г. Однако даже то, что уже известно очень настораживает – часть утечки, которая возможно содержала пользовательские данные, могла попасть в кэш поисковиков. Потенциально это дает возможность большего распространения приватных данных, чем непосредственно сама утечка.

Cloudbleed был обнаружен