Упрощённый пример использования из прошлого поста

SPL
Про всё это я уже писал. Как верно отметили в комментариях, идее уже сто лет в обед, ну или как минимум 15. История на этом не заканчивается, она только начинается.
Ясно что, но почему?
До ката был поставлен важный вопрос — почему память утекает? Отладочные утилиты как правило говорят, где был объект или массив создан, но не где он должен быть удалён. И topleaked тут не исключение. Понять, почему тот или иной кусок памяти не был освобождён, может только программист, найдя ошибочный сценарий. Но что если пойти дальше поиска типов? Если мы можем пройтись по всем объектам, которые считаем утёкшими, то мы можем искать общие черты среди них. Приведу реальный пример, историю, ради которой была написана новая фича.
Ближе к делу и… проблемам
Есть сервис. Он существенно нагружен, через него проходят сотни тысяч пользователей. Утечка любой мелочи на каждый запрос или подключение смерти подобна — взорвётся за считанные минуты. Сервис был отлажен и проработал 3 месяца без перезапуска процесса. Не рекордный аптайм, но всё же. И вот через 3 месяца мы выясняем, что всё это время он по чуть-чуть подтекал. Вроде бы мелочь, он превысил своё штатное потребление раза в 2-3 — перезапустил и забыл. Но вместе с памятью текли файловые дескрипторы. Поскольку сервис полностью сетевой, то эти дескрипторы — незакрытые сокеты, а значит у нас проблема в логике. Сервис написан почти полностью на C++ с очень небольшими вкраплениями перла. Это на самом деле мало влияет на последующее повествование, но от конкретики отталкиваться проще. С тем же успехом можно было допустить ту же ошибку на C, D, Rust, Go или NodeJS. И искать её можно точно так же, разве что с js были бы проблемы.
Метод глядения в код нам ничего не дал. Все возможные, как мне тогда казалось, сценарии использования сетевых соединений приводят к потере ссылок на объект, что благодаря умному указателю приводит к деструктору, который безусловно сделает close. Анализ и мониторинг дал оценку, что не закрывается примерно каждый сотый сокет. Сессии долгие (игровые сессии клиентов игры), поэтому для того, чтобы упереться в ограничение открытых fd на процесс (512000 в нашем случае) понадобились месяцы. Найти в логах признаки от этих незакрытых клиентов тоже не удавалось. На первый взгляд всё открытое закрывалось. Смотреть было больше некуда, и я полез читать дамп памяти процесса, снятый незадолго до достижения максимума открытых соединений.
Набираем статистику
Первый запуск topleaked сообщил очевидный факт — утекают объекты клиентских подключений. Спасибо, капитан, это мы уже и так знали по незакрытым сокетам. Нас интересует специфика этих подключений, ведь основная масса исправно помирает, когда положено. И вот тут зародилась идея: что если пройтись по всем этим объектам в дампе и посмотреть их состояние. В данном случае у нас в классе было свойство state — enum, отвечающий за логическое состояние клиента. Условно говоря: не подключен, подключен, прошёл хэндшейк websocket, прошла авторизация. Если знать, из какого состояния объекты утекают, то и искать проще.
Тут есть загвоздка. Topleaked не понимает форматов дампов, он просто открывает файл как бинарный поток, режет по 8 байт и строит топ самых частых 8-байтовых последовательностей. Это не какой-то сложный замысел, так было проще написать первую версию, ну а дальше нет ничего более постоянного, чем что-то временное. Вот только из-за отсутствия структуры невозможно понять, где лежат нужные нам значения. Всё, что у нас есть это значение указателя на vtbl, интересующего нас класса. А ещё мы знаем, что эти указатели, как и все свойства “лежат в объекте”. То есть можно поискать в дампе интересующий указатель на vtbl и по какому-то смещению относительно найденной позиции в файле будет лежать state. Это смещение фиксированное, так как зависит только от лейаута класса. Осталось только найти это смещение.
В случае C++ есть проблема — отсутствие ABI или каких-нибудь внятных правил расположения свойств в объектах. Для POD или trivial типов есть чёткие правила ещё из мира C. А вот расположение указателя на виртуальную таблицу, как и само существование виртуальной таблицы, не стандартизировано. К счастью на практике всё просто. Если не сильно мудрить с множественным наследованием и рассматривать конечный класс в иерархии, то на linux gcc выяснится, что vtbl — первое свойство объекта. А значит offsetof(state) и есть наше смещение. На более простом примере это выглядит так:

Здесь мы распечатали offsetof Der::a, “утекли” 10000 объектов и упали. Для начала запустим topleaked в штатном режиме

0x000055697c45cd78 это указатель на vtbl класса Der. offsetof равен 8. Значит нужно поискать этот указатель, отступить на 8 и прочитать значение. Для поиска воспользуемся отдельным режимом работы topleaked — поиском. Флаг -f отвечает за то, что будем искать в дампе, --memberOffset — смещение интересующего поля относительно найденного в -f, а --memberType — тип поля. Поддерживаются uint8, uint16, uint32 и uint64.

Получаем:

Мы видим 10000 значений 0x0f, которые сами и записали, а так же небольшой шум.
Happy End
В реальной ситуации всё работает примерно так же. Сначала в тестовом окружении я убедился, что смещение корректно и поиск находит то, что нужно, а потом запустил на реальном дампе. Полученный вывод сначала удивил, а потом порадовал. Нашлось несколько тысяч авторизованных клиентов, цифры соответствовали количеству онлайн пользователей на момент падения. Но самое главное, что нашлись сотни тысяч не просто неавторизованных, а объектов в самом первом состоянии. Это состояние означает, что клиенты подключились к серверу по TCP, но не послали ни байта — ни websocket upgrade, ни чего-нибудь неожиданного. Они подключились и молчали. Это самое простое место для отладки — нашего кода минимум, значит и ошибаться негде. Оказалось всё просто, автор кода (каюсь, это был я) не понимал гарантий TCP. Если не включать дополнительных опций и не пытаться ничего делать с сокетом, то невозможно никак понять, что он отключился. Нет встроенных пингов или таймаутов неактивности по умолчанию. Есть только расширение, которое все поддерживают, но которое выключено — TCP Keep Alive. Подробнее можно прочитать https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/
Самое неприятное то, что на самом деле мы про это знали. В игровой протокол добавлена похожая логика с проверкой неактивных сокетов, и она работает. Только включается она после установления websocket соединения. Поэтому и утечке были подвержены только те, кто потерял связь до посылки первого пакета.
Ещё немного про D
Не могу не отметить, как просто было добавить описанный выше функционал. Если посмотреть коммит, то мы увидим, что для каждого поддерживаемого типа данных (uint 8/16/32/64) добавилось по строке:

findMember — новая функция, реализующая смещение, а findMostFrequent — та же самая функция, которая строит топ самых частых значений. Благодаря шаблонам и алгоритмам на диапазонах (ranges) не потребовалось ничего менять. При том, что изначально эта функция работала с массивами, а теперь ей отдали весьма своеобразный итератор, который ищет и прыгает по файлу.