Как отладить бесследный сбой

Question

Во время разработки нашего приложения мы, в частности, столкнулись с очень неприятной ошибкой. Симптом довольно прост, что процесс исчезает. Журналы просто внезапно заканчиваются, никаких аварийных дампов или чего-либо еще не может быть найдено, никаких процессов зомби не существует. Доктор Ватсон ничего не заметил, оставив нас без следа.

Ошибка не просто воспроизвести, для воспроизведения этой ошибки требуется в среднем 3-4 часа, повторяя одни и те же действия. Так что где-то есть какое-то состояние гонки. У нас есть специальные функции, обрабатывающие как SEH, так и обычные исключения, поэтому ни одна из них не должна остаться незамеченной.

Отладка должна выполняться на специальном компьютере, потому что он работает на очень специализированном оборудовании. Так что доступна только удаленная отладка. И когда удаленная отладка подключена, C ++ builder не заметил, что приложение отсутствует, и аварийно завершает работу, когда мы пытаемся выполнить любую отладку на несуществующем процессе.

Мы используем большое разнообразие технологий с этим программным обеспечением:

• OpenGL
• Directshow + некоторые фильтры COTS
• COM / DCOM
• Последовательные COM-порты для связи со специализированным оборудованием
• C ++ Builder (который использует другие стековые рамки, чем VC ++)

Итак, как вы понимаете, мне не с чем здесь работать. Что я делаю сейчас, так это то, что я пытаюсь сузить его, войдя в разные места кода, чтобы найти, есть ли в коде конкретная точка, в которой возникает ошибка. Я также пытаюсь удалить как можно больше аспектов действия, которое я выполняю, чтобы сделать кейс как можно более простым. Но это действительно сложная операция, и этот процесс занимает много времени, а время (как обычно) является дефицитным ресурсом.

Мне интересно, есть ли у кого-нибудь хорошие советы для меня, либо по причине (вообще, что вызывает процесс просто останавливаться без какого-либо уведомления), либо по методам отладки такого неуловимого сбоя?

Answer 1

Когда собственный код в Windows испытывает переполнение стека (обычно из-за бесконечной рекурсии), процесс иногда исчезает точно так, как вы описали. Стандартные диалоги ошибок и обработка исключений требуют некоторого стекового пространства, и там, где их нет, они не могут работать. (Более поздние версии Windows справляются с этим лучше, и должен всегда вызывать исключение - Windows XP не является "более поздней" по этому определению.)

Самый простой способ отладки - это записывать сообщения журнала при входе (и, возможно, выходе) в каждую функцию. Эти сообщения имеют для прямого перехода к файлу, и, если у вас есть буферизованный вывод (например, cout или аналогичный), вы должны каждый раз немедленно очищать его. Когда вам удастся вызвать сбой, у вас будет близкая трассировка стека, которая может хотя бы локализовать проблему.

---

Бесконечная рекурсия - не единственная причина переполнения стека (хотя это более распространенная причина). Если в стеке размещены очень большие переменные (обычно массивы с тысячами / миллионами элементов), может возникнуть та же проблема. В частности, alloca() «функция» может скрыть причину этого типа переполнения стека.

Если вы работаете в отладчике и разбиваете / регистрируете исключения страницы защиты, вы будете уведомлены о расширении стека - разрешите обработать исключение, поскольку оно используется для фиксации большего объема памяти и может фактически не быть связано выпуск.

---

Последней причиной исчезновения процесса при переполнении стека является случайный вызов exit() или ExitProcess(). Полнотекстовый поиск должен в основном исключать это - точка останова на функции ExitProcess в отладчике сделает это полностью.

Answer 2

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

Answer 3

Почему бы вам не попробовать windbg, он также может подключаться удаленно через именованный канал или последовательный порт.

---

НЕТ BSOD, нет руткитов, нет веселья ~~ Biswanth Chowdhury - Win32 Kernel *

Answer 4

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

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