Комментарии 8
Интересный баг, спасибо. Ковырять дампы это всегда увлекательное занятие, но чаще всего требует очень много времени. Для некоторых сценариев порой проще воспользоваться автоматическим анализом в последней студии (дока), можно открывать в том числе и Linux дампы. Для .NET Framework дампов может помочь Debug Diagnostic Tool
21й век на дворе. Народ упорно вводит команды...
Чем плохи команды... играю я в elite dangerous в VR шлеме c voxcommando. Заходит брат и говорит: самоуничтожение. Вот было весело. Хорошо хоть подтверждение запросило.
На самом деле, это удобно тем, что можно зайти по RDP/SSH на машину, где сейчас есть проблемы с процессом и прямо там в консоли всё отдебажить. Порой дампы очень большого размера, порой под рукой нет машины с нужным окружением и инструментами для дебага не через команды :) А вообще, главное понимать общие подходы, чтобы в любом инструменте для дебага осознавать, что делать и куда смотреть.
Не. Это не то про что я говорил. Это "на безрыбье и рак рыба". Это от безысходности. Все команды сверху (список нитей, переход на нить, посмотреть стек) это ровно один даблклик. Именно один. Если говорить что "как это по ремоте сделать?", так то не тот вопрос, что задавать надо. Правильный вопрос - "а какого в 21 веке так до сих пор нельзя" (на самом деле можно).
Консоль дает протокол вашего эксперимента. Информация с предыдущих шагов под рукой, можно найти где ошибся при переходах, восстановить путь по ним. Photoshop для примера куда более естественно подходит для работы с мышью, но история в нем отображается текстом в виде команд.
Ну хорошо. Допустим история - это валидный аргумент. Да только не в данном случае. Тут у нас интерактивная по свое сути сессия и вместо того, чтобы искать где ошибся проще заново повторить действия. Кроме того деструктивные действия повторить не удастся и история в этом никак не помогает / не мешает.
И вообще я вовсе не хотел поднимать старый как мир спор консоль против GUI. Просто в данном конкретном случае вместо того, чтобы заниматься отладкой предлагается помнить(!) целый предметно-ориентированый язык, знание которого нигде больше не пригодится. Причем примерно понятно откуда возник этот язык - разработчик явно открыл для себя волшебный мир gdb (может и опосредовано через windbg & co.). Это обидно - ресурс потрачен впустую и вместо нормального отладчика мы имеем полуфабрикат.
Уххх. Дампы ковырять- навык, который раз в два года, но очень нужен. У меня давеча rest api задедлочилось. Раз в три дня вставал колом. Бага была в gc, а точнее в версии glibc на Linux машине. Но чтобы понять что проблема именно там, а не у меня- надо было очень догадаться :) «как так, я же на неблокирующих алгоритмах делал, откуда дедлок, да ещё такой жесткий». Обычно смотришь в дамп: «так, это фрейм сборщика, понятно, что дальше». А проблема именно в нем была. Короткий совет- переезжайте на 21 убунту:)
Ищем дедлок в .NET 5 с помощью анализа дампа