.NET Core становится всё более и более зрелой платформой. На нём уже достаточно комфортно можно вести разработку, используя тот же Rider или VS Code. Однако, и там не всё гладко. Например, отладка кода на .NET Core 2 заработала только в Rider 2017.2, который вышел, буквально на днях (были ещё EAP сборки). Приходилось пользоваться VS Code. В нём работает отладка, однако, чтобы заработал запуск тестов надо руками ставить beta-версию расширения для C#. Я думаю, суть ясна, что инструментальная поддержка пока сильно далека от аналогичной при разработке под Windows. Для некоторых вещей пока нету готовых средств. Например, для профилирования. Из источников, которые доступны в сети, самыми содержательными, по моему мнению, на текущий момент являются статьи Саши Гольдштейна: Однако, готового рецепта по поиску утечки памяти мне найти не удалось. Поэтому я решил описать найденный мной способ. Лично я бы, не долго думая, подключился к работающему приложению с помощью dotMemory, снял бы 2 снапшота через некоторый промежуток времени и сравнил бы их, используя, красивый GUI.  Как здорово было бы, если бы под Linux мы могли бы сделать что-нибудь похожее. Давайте попробуем. Тут ничего сложного. Конечно, не нужно прибегать ни к каким инструментам, чтобы найти утечку в следующем коде. Но для обучающих целей сгодится. Сделать подобный снапшот (core dump) под Linux для работающего приложения достаточно легко. Это делают следующие 2 команды: И через некоторое время делаем второй снапшот Мы получили 2 дампа нашего приложения: которые теперь можем попытаться сравнить. Microsoft предоставляет плагин для LLDB, который может нам с этим помочь. Это портированное расширение SOS из WinDBG с аналогичным набором команд. В теории, чтобы посмотреть аллокации памяти, имея полученный выше снапшот мы должны были бы выполнить следующие команды: В статьях у Саши Гольдштейна ещё устанавливается путь к CLR командой Но для исследования проблем с Debug-сборкой моего тестового приложения мне это не понадобилось. Microsoft поставляет libsoplugin.so вместе с .NET Core. Так что, скорее всего он у вас есть в системе. Как писал Саша в своей статье, к сожалению, этот плагин линкуется с конкретной версией LLVM. Соответственно, потребуется конкретная версия LLDB, чтобы им воспользоваться. Посмотреть конкретную версию, уже не получится как раньше, с помощью команды ldd: Дело в том, что liblldd.so в разных дистрибутивах назывался по-разному и его убрали из явных зависимостей. В каком-то из issues на GitHub есть информация, что в .NET Core 2.0 этот плагин собран с lldb-3.8, а версия в .NET Core 2.0.1 уже будет собрана с lldb-3.9. Казалось бы, теперь мы знаем версию и можем просто поставить в систему lldb нужной версии. Но нет. Дело в том, что lldb до версии 4.0 не мог грузить on-demand core dump. Как раз такие, какие мы и сделали (в процессе работы программы). К счастью, нам понадобится только плагин. Не придётся использовать кастомный .NET Core и т.д. Плагин будем использовать прямо из папки, в которой мы его соберём, так что система не замусорится. Собственно, в репозитории CoreCLR есть инструкции по сборке под Linux. Мы только немного подправим их, чтобы воспользоваться lldb-4.0. Я использую Ubuntu 16.04. Для других дистрибутивов набор команд может несколько отличаться. Ставим необходимые инструменты для сборки: Клонируем репозиторий: Применяем следующий патч: Собираем CoreCLR: Ура, мы получили работающий плагин для lldb-4.0. Открываем наш снапшот в lldb: Загружаем собранный плагин: Дампим статистику по использованию кучи: Первая колонка — это адрес method table для объектов данного класса, вторая — количество аллоцированных объектов данного класса, третья — количество аллоцированных байт, четрвёртая — имя класса. По выводу не сложно догадаться, кто же течёт. Получаем стек, в котором создан объект (команды могут выполняться ооочень долго): Получаем огромную таблицу в которой первая колонка — адрес инстанса этого класса, вторая — адрес method table, третья — размер инстанса в байтах. Выбираем какой-нибудь инстанс и выполняем команду: И как видим, нам указывают как раз на строку в исходном файле. Раз уж я начал с разговора о сравнении снапшотов, придётся хоть как-то их сравнить. Сохранив в файлы dump1.txt и dump2.txt выводы команд sos DumpHeap -stat для обоих снапшотов (я просто скопировал из консоли), я обработал их вот таким простым скриптиком (на самом деле я писал прямо в консоли iPython, поэтому на скрипт это не очень похоже): Получив в результате, список "горячих точек" на которые стоит обратить внимание:  Надеюсь, такой вот, импровизированный, способ поиска утечек памяти будет кому-нибудь полезен. Внимательный читатель, конечно же, заметит, что было бы неплохо, автоматизировать весь процесс, с помощью скриптов lldb. Но пока у меня нету времени на это. Не удалось сходу решить проблему с тем, что python-lldb-4.0 установленный из репозитория отказывается грузить libsoplugin.so. Возможно, кто-то ещё продвинется дальше. Спасибо за внимание!