У меня есть проект на C++, который я использую с travis-ci. Прямо сейчас я строю его с помощью boost.build, а на travis, когда я запускаю модульные тесты, я делаю это через gdb
, так что я получаю обратную трассировку в случае сбоя.Вызывать `cdb.exe` (windbg) для запуска невзаимодействующим образом и производить обратную трассировку в случае сбоя?
Для того, чтобы сделать это gdb
неинтерактивным, я призываю его, как это в командной строке:
gdb -return-child-result -batch -ex "run" -ex "thread apply all bt" -ex "quit" --args ./${file}
где ${file}
мой исполняемый файл.
Это говорит о его:
- начать процесс
- ОТНОСИТЬСЯ
bt
для всех потоков, которые излучает трассировку в случае аварии, а также не делает ничего, если бы не было никакой аварии. - Наконец, он вызывает
gdb
, чтобы выйти, и выйти с кодом выхода ребенка.
Теперь я хотел бы сделать то же самое на appveyor.
Boost build, похоже, отлично работает из коробки в виртуальной машине для приложений, так что шляпы от них.
Однако я стараюсь выяснить, как настроить cdb
, кузена консоли windbg
. Кажется, он висит в моих журналах сборки. Большинство примеров, которые я нахожу в Интернете, связаны с проверкой файлов minidump, а не с запуском процесса и отладки его при его запуске.
Я в настоящее время вызова cdb
как это (от appveyor Powershell скрипт):
cdb -c "$$><cdb_script.txt" -o $file.fullName
И мой cdb_script.txt
выглядит
.sympath srv*C:\Windows\Symbols*http://msdl.microsoft.com/download/symbols;
.reload;
~* k 99;
q
Я в основном брусчатки это вместе из различных вещей, которые я гугле , включая
- https://msdn.microsoft.com/en-us/library/windows/hardware/ff560096(v=vs.85).aspx
- http://www.sandboxie.com/index.php?HowToUseWinDbg
Я действительно надеялся найти лучший доку или примеры о том, как это сделать конкретно.
Я получаю ошибку прямо сейчас:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\projects\primer\test\stage\api.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 009a0000 00a27000 api.exe
ModLoad: 76fb0000 7711f000 ntdll.dll
ModLoad: 76520000 76660000 C:\windows\SysWOW64\KERNEL32.DLL
ModLoad: 75fb0000 76087000 C:\windows\SysWOW64\KERNELBASE.dll
ModLoad: 74350000 743f0000 C:\windows\SysWOW64\apphelp.dll
SHIMVIEW: ShimInfo(Complete)
ModLoad: 73b20000 73bd9000 C:\windows\SysWOW64\MSVCP140D.dll
ModLoad: 741b0000 741cc000 C:\windows\SysWOW64\VCRUNTIME140D.dll
ModLoad: 71bd0000 71d46000 C:\windows\SysWOW64\ucrtbased.dll
(294.49c): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
eax=00000000 ebx=00000000 ecx=19a00000 edx=00000000 esi=7ecdf000 edi=00000000
eip=77063c7d esp=0110f8d4 ebp=0110f900 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrInitShimEngineDynamic+0x6dd:
77063c7d cc int 3
0:000> cdb: Reading initial command '><cdb_script.txt'
^Syntax error in '><cdb_script.txt'
Некоторые вариации я пробовал:
- Использование
$$<cdb_script.txt
вместо$$><cdb_script.txt
. - Поставив точку с запятой после последней команды в файле сценария
Edit: я нашел и this answer, что объясняет снова, как сделать это с минидампов но показывает файл сценария более подробно.
Я действительно не знаю, что такое minidump tbh, поэтому -o
вариант звуков более привлекателен, по крайней мере, больше похож на gdb
. Но, возможно, я в конечном итоге попытаюсь сделать это с помощью мини-дисков, если не смогу это понять.
Я в конечном итоге не используя скрипт cdb, выясняется, что мой скрипт действительно не так долго, но спасибо за этот указатель –