В сентябре 2025 года Apple выпустила очередную версию своей настольной ОС — macOS Tahoe 26. Все ждали новых возможностей, улучшенного интерфейса и инновационный Liquid Glass. Но, уверен, никто не ожидал, что столкнется с проблемами утечки памяти, причем из-за таких базовых приложений, как «Калькулятор» и «Сообщения».
Давайте разберемся, какие причины могли спровоцировать столь странное поведение программ и как получилось, что его не заметили опытные QA-инженеры Apple.
Привет! Данная статья обязательна к прочтению всем, кто работает с Vue SSR, в частности с Nuxt. Речь пойдет об утечке памяти при использовании axios.
Пол года назад я попал на проект со стеком VueJS + Nuxt, его особенность была в том, что в проде постоянно умирали нодовские сервера(Nuxt) и на их места поднимались новые. По графикам и логам было видно, что оператива процесса ноды доходила до 100% и она падала с ошибкой out of memory. В это время на место убитого процесса поднимался новый, на что уходило порядка 30 сек., этого хватало, чтобы пользователи успели получить 502 ошибку. Очевидно, что где-то в коде была утечка памяти, которую нужно было найти.
Читать полностью »
Привет! Представляю вашему вниманию перевод статьи «Demystifying memory management in modern programming languages» за авторством Deepu K Sasidharan.
В данной серии статей мне бы хотелось развеять завесу мистики над управлением памятью в программном обеспечении (далее по тексту — ПО) и подробно рассмотреть возможности, предоставляемые современными языками программирования. Надеюсь, что мои статьи помогут читателю заглянуть под капот этих языков и узнать для себя нечто новое.
Углублённое изучение концептов управления памятью позволяет писать более эффективное ПО, потому как стиль и практики кодирования оказывают большое влияние на принципы выделения памяти для нужд программы.
Читать полностью »
Как правило, профилировщики памяти начинают использовать тогда, когда приложение уже гарантированно «течёт», пользователи активно шлют письма, пестрящие скриншотами диспетчера задач и нужно потратить уйму времени на профилирование и поиск причины. Наконец, когда разработчики обнаруживают и устраняют утечку, выпускают новую прекрасную версию приложения, лишенную прежних недостатков, есть риск, что через некоторое время утечка вернется, ведь приложение растет, а разработчики все также могут допускать ошибки.
Автоматизированное регрессионное тестирование ошибок уже давно стало мейнстримом индустрии разработки качественного ПО. Такие тесты помогают не допустить попадание ошибки к пользователю, а также по горячим следам разобраться, какое изменение в коде привело к ошибке, тем самым минимизировав время ее исправления.
Почему бы нам не применить такой же подход к утечкам памяти?
.NET Core становится всё более и более зрелой платформой. На нём уже достаточно комфортно можно вести разработку, используя тот же Rider или VS Code.
Однако, и там не всё гладко. Например, отладка кода на .NET Core 2 заработала только в Rider 2017.2, который вышел, буквально на днях (были ещё EAP сборки). Приходилось пользоваться VS Code. В нём работает отладка, однако, чтобы заработал запуск тестов надо руками ставить beta-версию расширения для C#.
Я думаю, суть ясна, что инструментальная поддержка пока сильно далека от аналогичной при разработке под Windows.
Для некоторых вещей пока нету готовых средств. Например, для профилирования.
Из источников, которые доступны в сети, самыми содержательными, по моему мнению, на текущий момент являются статьи Саши Гольдштейна:
Однако, готового рецепта по поиску утечки памяти мне найти не удалось. Поэтому я решил описать найденный мной способ.
Хабра, привет!
Не так давно у со мной произошел довольно-таки интересный инцидент, в котором был замешан один из преподавателей одного колледжа информатики.
Разговор о программировании под Linux медленно перешел к тому, что этот человек стал утверждать, что сложность системного программирования на самом деле сильно преувеличена. Что язык Си прост как спичка, собственно как и ядро Linux (с его слов).
У меня был с собой ноутбук с Linux, на котором присутствовал джентльменский набор утилит для разработки на языке Си (gcc, vim, make, valgrind, gdb). Я уже не помню, какую цель мы тогда перед собой поставили, но через пару минут мой оппонент оказался за этим ноутбуком, полностью готовый решать задачу.
И буквально на первых же строках он допустил серьезную ошибку при аллоцировании памяти под… строку.
char *str = (char *)malloc(sizeof(char) * strlen(buffer));buffer — стековая переменная, в которую заносились данные с клавиатуры.
Я думаю, определенно найдутся люди, которые спросят: «Разве что-то тут может быть не так?».
Поверьте, может.
А что именно — читайте по катом.
Читать полностью »
Недавно у нас закончился крупный проект с довольно сложным продвинутым UI. Не вдаваясь в детали, скажем, что внутри браузера было реализовано что-то вроде рабочего стола (desktop) с окнами, перекрытиями и всем, чем полагается. Разумеется, проблемы с утечками памяти не обошли нас стороной. Признаемся честно, до поры до времени сосредоточились на получении бизнес-результата. Когда дошли руки до утечек памяти, то обнаружилось, что окна браузера занимают гигабайты оперативной памяти. Мы классифицировали ошибки и в общем виде выработали подход к их устранению. Этим подходом и хотим поделиться с вами.
По теме утечек памяти в клиентских приложениях написано уже немало. Изначально основную проблему представляли из себя браузеры IE8 и младших версий (смотрите, например:
http://habrahabr.ru/post/141451/
http://habrahabr.ru/post/146784/
https://learn.javascript.ru/memory-leaks).
Но и теперь, когда можно сказать, что IE8 в прошлом, проблемы остаются. Даже применение такого языка как TypeScript не гарантирует их отсутствия. А с учетом того что front-end в web-приложениях становится все сложнее, актуальность проблемы только возрастает.
Читать полностью »
Добрый день.
Примерно 2 недели назад наш мониторинг тул (NewRelic) начал детектить большое количество падений сайта продолжительностью не более 1 минуты, но с очень большой периодичностью. Помимо этого визуально было заметно, что общая производительность веб-приложения (Umbraco 6.1.6, .net 4.0) упала.
Красные полосы на картинке — это и есть наши падения.
Да, оговорюсь. Перед тем, как мы это все заметили, новый модуль для блога был установлен и соответственно блог компании был мигрирован из Worldpress в Umbraco.
В итоге у нас есть следующие входные данные: приложение стало хранить больше данных (намного больше) + был установлен сторонний модуль = High CPU.
Читать полностью »
Здравствуйте, уважаемые читатели.
В этом коротком посте я хочу поделиться с вами некоторыми моментами, с которыми столкнулся при разработке одного из своих приложений (читалка для Windows). Речь пойдет о DirectX и, как мне показалось, странных утечках памяти.
Для отображения содержимого страниц я решил использовать DirectX. Задумка была проста: сначала создаю 2D-текстуру с текстом, а потом отображаю 3D модель с использованием подготовленных ранее текстур. Это дает мне возможность делать анимацию 3D перелистывания страниц.
Как-то так:
В момент выпуска приложения в магазин я ожидал всеобщего восхищения. Но не тут-то было. Пользователи оказались недовольны. Анализ ситуации показал, что течет память. И очень хорошо течет. Но почему? Этого я долго не мог понять.
С учетом того, что приложения в Windows 8.1 и Windows Phone 8.1 полностью не выгружаются при «закрытии», утечки памяти накапливались.
Читать полностью »
В руби реализовано автоматическое управление памятью. В большинстве случаев это хорошо. Но, к сожалению, иногда это бывает больно.
Менеджер памяти руби одновременно и элегантен, и не лишен странностей, в любую минуту готовых обернуться неприятным сюрпризом. Руби хранит объекты (RVALUE) в так называемой куче (это не heap в классическом понимании c-программистов, у руби своя куча). На низком уровне, RVALUE — это обычная c-struct, состоящая из области «атрибутов» и собственно области «данных». Подробный рассказ о том, как внутри хранятся объекты выходит за рамки данной заметки; достаточно просто понимать, что каждому объекту в руби соответствует такой вот RVALUE. Сборщик мусора считает ссылки на него, и очищает слот, когда счетчик обнуляется. В чисто академических целях скажу, что размер каждого такого слота зависит от архитектуры:
/*
* sizeof(RVALUE) is
* 20 if 32-bit, double is 4-byte aligned
* 24 if 32-bit, double is 8-byte aligned
* 40 if 64-bit
*/
Итак, у нас есть слоты (это принятое название, slot), размером около сорока байт, в которых хранятся… Вот тут и начинается самое интересное. Там не просто хранятся ссылки на объекты, размещенные в настоящей системной куче, как, наверное, подумали люди, знакомые с реализацией более традиционных сборщиков мусора.