Привет.

Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще. Баг относительно повторяемый, где-то в 50% запусков наблюдается, но, при этом, случается в разные моменты времени. Например, программа может проработать 30 минут, а может час а может и все 8 часов. Такие "выходы" однозначно не нормальные, так как при нормальном выходе создается файл отчета, а тут его нет. Никакого "умного" софта, который мог бы это провоцировать на компе не стоит, да и наблюдалось на разных компах.

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

Любые советы приветствуются. Спасибо заранее.

PS: VC++ 7.1, MFC, unmanaged, WinXP/Win2000Pro, multithreaded.

M>Любые советы приветствуются. Спасибо заранее.

1) Запусти программу из под деббагера с включеной диагностикой.
Гоняй под деббагером сколько надо, пока прога не свалится.

2) Пиши все что надо в лог файл. Потом его анализируй.

Здравствуйте, mymus, Вы писали:

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.
M>Любые советы приветствуются. Спасибо заранее.
M>PS: VC++ 7.1, MFC, unmanaged, WinXP/Win2000Pro, multithreaded.

Вполне может быть где-то неинициализированно что-то, или поток сам себя пришибает.
Много разных вариантов... Былоб это в linux, я бы приложение под valgrind погонять порекомендовал,
под видндой сложнее. Eсть Purify,
но денег стоит... 1,370 американских рублей. Хотя можно под бетой/триалом погонять.

Здравствуйте, mymus, Вы писали:

M>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще. Баг относительно повторяемый, где-то в 50% запусков наблюдается, но, при этом, случается в разные моменты времени. Например, программа может проработать 30 минут, а может час а может и все 8 часов. Такие "выходы" однозначно не нормальные, так как при нормальном выходе создается файл отчета, а тут его нет. Никакого "умного" софта, который мог бы это провоцировать на компе не стоит, да и наблюдалось на разных компах.

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

Я бы для начала сделал поиск в коде и используемых библиотеках по словам "ExitProcess", "exit", "TerminateProcess", "abort" и т.п. Затем проверил unhandled exception filter — не скрывает ли он простой GPF. (По настроению, побить того, кто так делает.)

Если всего этого нет, то отладить будет гораздо проще.

Здравствуйте, mymus, Вы писали:

M>Привет.

M>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще. Баг относительно повторяемый, где-то в 50% запусков наблюдается, но, при этом, случается в разные моменты времени. Например, программа может проработать 30 минут, а может час а может и все 8 часов. Такие "выходы" однозначно не нормальные, так как при нормальном выходе создается файл отчета, а тут его нет. Никакого "умного" софта, который мог бы это провоцировать на компе не стоит, да и наблюдалось на разных компах.

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

M>Любые советы приветствуются. Спасибо заранее.

M>PS: VC++ 7.1, MFC, unmanaged, WinXP/Win2000Pro, multithreaded.


Возникла идея
поставь breakpoint в atexit
гоняй под дебагом пока не вывалиться
и посмотри на стек
может чего полезного и увидишь

Здравствуйте, serega, Вы писали:

[]

S>Возникла идея
S>поставь breakpoint в atexit
S>гоняй под дебагом пока не вывалиться
S>и посмотри на стек
S>может чего полезного и увидишь

atexit вызывается лишь в случае нормального завершения (exit()).

Здравствуйте, mymus, Вы писали:

M>Привет.

M>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще. Баг относительно повторяемый, где-то в 50% запусков наблюдается, но, при этом, случается в разные моменты времени. Например, программа может проработать 30 минут, а может час а может и все 8 часов. Такие "выходы" однозначно не нормальные, так как при нормальном выходе создается файл отчета, а тут его нет. Никакого "умного" софта, который мог бы это провоцировать на компе не стоит, да и наблюдалось на разных компах.

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

M>Любые советы приветствуются. Спасибо заранее.

M>PS: VC++ 7.1, MFC, unmanaged, WinXP/Win2000Pro, multithreaded.

вставлю свои 5 копеек...
я бы начал со следующего
1) включил в студии обработку всех брошенных исключений (по умолчанию студия ловит только необработанные)
2) Поставил брекпоинты на адреса функций ExitProcess, TerminateProcess, ... На всякий случай объясню как это сделать 8)
Адреса функций в DLL можно посмотреть утилитой Depends. Ну а адрес функции в твоем процессе = DLL Base + Адрес функции
(для ExitProcess: 0x7c570000 (Kernel.dll base) + 0x00026972 (ExitProcess entry point) = 0x7C596972)

Здравствуйте, Аноним, Вы писали:

А>2) Поставил брекпоинты на адреса функций ExitProcess, TerminateProcess, ... На всякий случай объясню как это сделать 8)
А>Адреса функций в DLL можно посмотреть утилитой Depends. Ну а адрес функции в твоем процессе = DLL Base + Адрес функции
А>(для ExitProcess: 0x7c570000 (Kernel.dll base) + 0x00026972 (ExitProcess entry point) = 0x7C596972)

Надо сделать Add Breakpoint и в диалоге ввести прямо имя функции (e.g. DeleteFileA, ExitProcess etc.). И всё; Depends не нужен, адрес функции знать тоже не нужно, хотя в релиз-билде не все функции могут быть найдены отладчиком.

Я все-таки советую начать с перелопачивания исходников на предмет вызовов ExitProcess и исключений, а не с плясок с бубном

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Аноним, Вы писали:

А>>2) Поставил брекпоинты на адреса функций ExitProcess, TerminateProcess, ... На всякий случай объясню как это сделать 8)
А>>Адреса функций в DLL можно посмотреть утилитой Depends. Ну а адрес функции в твоем процессе = DLL Base + Адрес функции
А>>(для ExitProcess: 0x7c570000 (Kernel.dll base) + 0x00026972 (ExitProcess entry point) = 0x7C596972)

Кё>Надо сделать Add Breakpoint и в диалоге ввести прямо имя функции (e.g. DeleteFileA, ExitProcess etc.). И всё; Depends не нужен, адрес функции знать тоже не нужно, хотя в релиз-билде не все функции могут быть найдены отладчиком.

хм...
не получилось...
да и с чего оно должно работать...
откуда студии знать где этот ExitProcess пресловутый...
может Debug символы для винды нужны чтоб так работало?

Кё>Я все-таки советую начать с перелопачивания исходников на предмет вызовов ExitProcess и исключений, а не с плясок с бубном

ну незнаю, когда непонятно что происходит а исходников много, да ещё часть не твоих...
можно долго их перелопачивать, а так, если в ExitProcess встанет, то по стеку сразу всё будет понятно
на то он и бубен что решает всё и сразу, другой вопрос, что не всегда работает 8)

Здравствуйте, mymus, Вы писали:

M>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще.
такое поведение наблюдается при stack overflow. покапай в этом направлении. поищи рекурсивные вызовы, выделение памяти на стеке (см. alloca), нестандартные пути выполнения — раз уж не всегда падает, то возможно ошибка в какой-то одной ветке.

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

можно обложить всю программу try/catch и смотреть, что поймалось.

Здравствуйте, shurik., Вы писали:

S>Здравствуйте, Кодёнок, Вы писали:

Кё>>Здравствуйте, Аноним, Вы писали:

А>>>2) Поставил брекпоинты на адреса функций ExitProcess, TerminateProcess, ... На всякий случай объясню как это сделать 8)
А>>>Адреса функций в DLL можно посмотреть утилитой Depends. Ну а адрес функции в твоем процессе = DLL Base + Адрес функции
А>>>(для ExitProcess: 0x7c570000 (Kernel.dll base) + 0x00026972 (ExitProcess entry point) = 0x7C596972)

Кё>>Надо сделать Add Breakpoint и в диалоге ввести прямо имя функции (e.g. DeleteFileA, ExitProcess etc.). И всё; Depends не нужен, адрес функции знать тоже не нужно, хотя в релиз-билде не все функции могут быть найдены отладчиком.

S>хм...
S>не получилось...
S>да и с чего оно должно работать...
S>откуда студии знать где этот ExitProcess пресловутый...
S>может Debug символы для винды нужны чтоб так работало?
Решение "в лоб"
Ставишь софтайс (SoftICE), настраиваешь (нужно чтоб он понимал символы из Kernel32.dll, где наход. ExitProcess + еще что надо).
Ребутишься, т.к. сайс — драйвер.
Стартуешь сайс.
Запускаешь прогу.
входишь в консоль сайса.
переходишь с пом. ADDR в контекст процесса.
bpx ExitProcess

Смотришь на стэк вызовов.

J>Ставишь софтайс (SoftICE), настраиваешь (нужно чтоб он понимал символы из Kernel32.dll, где наход. ExitProcess + еще что надо).


8)
если человек не работал с айсом, не ставил Debug-символы, то уж проще через Depends
имею ввиду в рамкой данной задачи, т.е. поймать вызов определённой API-функции

Здравствуйте, shurik., Вы писали:


J>>Ставишь софтайс (SoftICE), настраиваешь (нужно чтоб он понимал символы из Kernel32.dll, где наход. ExitProcess + еще что надо).


S>8)
S>если человек не работал с айсом, не ставил Debug-символы, то уж проще через Depends
S>имею ввиду в рамкой данной задачи, т.е. поймать вызов определённой API-функции
вариант — WinDbg от MS неплохая замена сайсу.
К тому же гуёвая.

Здравствуйте, mymus, Вы писали:

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

M>Любые советы приветствуются.

Закомментировать всю функциональность. Чтобы был только примитивный старт/стоп.
Раскомментировать одну часть функциональности. Погонять как следует. Если не падает переходить к следующей части функциональности. И так до тех пор, пока не начнет ломаться.
Как только будет обнаружен компонент, в котором происходят сломы, работаешь с ним по той же схеме.

Такой способ подходит, если код чужой и под отладчиком запустить его не получается.

Здравствуйте, mymus, Вы писали:

M>Привет.

M>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще. Баг относительно повторяемый, где-то в 50% запусков наблюдается, но, при этом, случается в разные моменты времени. Например, программа может проработать 30 минут, а может час а может и все 8 часов. Такие "выходы" однозначно не нормальные, так как при нормальном выходе создается файл отчета, а тут его нет. Никакого "умного" софта, который мог бы это провоцировать на компе не стоит, да и наблюдалось на разных компах.

M>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

M>Любые советы приветствуются. Спасибо заранее.

M>PS: VC++ 7.1, MFC, unmanaged, WinXP/Win2000Pro, multithreaded.


запускаешь ntsd (он включен в Win2000 и далее),

например так
ntst notepad

ставишь break point, комманда bp, на выход
bp ntdll!ZwTerminateProcess

запускаешь прогу комманда g

перед выходом она остановится в отладке. Смотришь стек kb далее ствишь break на нужный вызов, если хочеться.

вот как это выглядит для notepad:
0006ff14 78007cd8 00000000 00072b47 78007c60 ntdll!ZwTerminateProcess
0006ffc0 7c59893d 0006f818 77f81f55 7ffdf000 msvcrt!exit+0x85
0006fff0 00000000 01006420 00000000 000000c8 KERNEL32!ProcessIdToSessionId+0x17d

Я бы поставил userdump и сделал бы memory dump при краше. Оттуда бы и плясал.
Посмотрел что на стеке, что в других потоках, что в памяти.
Нужен еще будет WinDBG.

Здравствуйте, AIDS, Вы писали:

AID>Я бы поставил userdump и сделал бы memory dump при краше. Оттуда бы и плясал.
AID>Посмотрел что на стеке, что в других потоках, что в памяти.
AID>Нужен еще будет WinDBG.

здесь

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, mymus, Вы писали:

M>>Проблема: приложение само по себе "закрывается", то есть исчезает из списка процессов вообще.
А>такое поведение наблюдается при stack overflow. покапай в этом направлении. поищи рекурсивные вызовы, выделение памяти на стеке (см. alloca), нестандартные пути выполнения — раз уж не всегда падает, то возможно ошибка в какой-то одной ветке.

Если со стеком связано, то можно попробовать поизменять размер стека. Например, вместо 1 Мб установить 100 кб или 100 Мб и поглядеть влияет ли это на скорость падения. Ну естественно статистически, раз она всё время через разное время падает.

Хотя MSVC прямо так и говорит, когда стек переполняется. По умолчанию по крайней мере. Сейчас запустил программу, скомпилированную под релиз под отладкой, он прямо так и сказал, что стек переполнился.

M>>Вопрос: как отдебагить? Вычитка кода ничего не дала. Поскольку кода довольно много да и проявляется всегда в разные моменты времени, просто поставить брейкпоинты вряд ли удастся.

А>можно обложить всю программу try/catch и смотреть, что поймалось.


Если проект большой, то конечно просматривать код и комментировать различные части программы — это, конечно, бредовая идея imho. Если комментировать, так вообще эта ошибка может не проявляться.
По собственному опыту могу сказать, что скорее всего связано с многопоточностью, раз так не регулярно проявляется. Я бы в первую очередь начал с изучения мест, где потоки обращаются с одним данным. Можно попробовать очень жестко всё защитить критическими секциями, что б уж точно не было конфликтов. И поглядеть будет ли ошибка проявляться.

Здравствуйте, Аноним, Вы писали:

M>>Любые советы приветствуются. Спасибо заранее.

А>1) Запусти программу из под деббагера с включеной диагностикой.
А>Гоняй под деббагером сколько надо, пока прога не свалится.

А>2) Пиши все что надо в лог файл. Потом его анализируй.

Вообще можно посмотреть стек вызовов (в студии) в дебуге. Он может дать какой-то результат — увидишь после какой функции вываливается А вообще я бы сделал лог файл и писал в него каждый вход-выход в функцию. Ну и после очередного обвала просмотрел бы.

M>Проблема: приложение само по себе "закрывается"

Всем спасибо за помощь.

Кстати, судя по всему, таки было переполнение стека. По крайней мере, увеличение размера стека до 5 Мб похоже, решило проблему: несколько запусков подряд не "падало".