时间戳

首页 > 解决方案 > 为什么 CrashDump.exe 挂起？如何进行调试？

gdb - 为什么 CrashDump.exe 挂起？如何进行调试？

问题描述

我正在使用来自https://github.com/adamgreen/CrashDebug的 CrashCatcher/CrashDebug 代码。我的平台是运行 freertos 的 STM32H753。我已经能够根据 CrashCatcher 中的 HexDump.c 示例生成转储文件。到目前为止，一切都很好。当我尝试运行 arm-none-eabi-gdb.exe 并将其连接到 CrashDebug.exe 时出现问题。我在 Windows 10 上运行并使用 stm32 工具链。我使用 mingw 在本地构建了 CrashDebug.exe。我运行以下命令行：

C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\bin\arm-none-eabi-gdb.exe "fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf" -ex "set target-charset ASCII" -ex "target remote | /Users/felix/source/Thor/CrashDebug.exe --elf C:\Users\felix\source\Thor\fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf --dump C:\Users\felix\source\Thor\crash.dmp"

这会运行 gdb，但命令解释器变得无响应并且永远不会返回到 gdb 提示符。我什至不能按 ctrl-c 来打破。我必须终止进程。这是挂起之前 gdb 输出的内容。

C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (GNU Tools for STM32 9-2020-q2-update.20201001-1621) 8.3.1.20191211-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf...
Remote debugging using | /Users/felix/source/Thor/CrashDebug.exe --elf C:\Users\felix\source\Thor\fw-10143-sensor-hub-stm32-firmware\Debug\THOR_1.5_Sensor_Hub_FW.elf --dump C:\Users\felix\source\Thor\crash.dmp

我希望 gdb 提示符会回来，这样我就可以得到堆栈跟踪。

我尝试运行 mingw gdb 的实例并连接到正在运行的 CrashDebug.exe 进程并停止它。当我这样做时，我得到以下堆栈跟踪。

(gdb) symbol-file c:/users/felix/source/Thor/CrashDebug/bins/win32/CrashDebug.exe
Load new symbol table from "c:\users\felix\source\Thor\CrashDebug\bins\win32\CrashDebug.exe"? (y or n) y
Reading symbols from c:\users\felix\source\Thor\CrashDebug\bins\win32\CrashDebug.exe...done.
(gdb) thread apply all bt

Thread 2 (Thread 3240.0x2804):
#0 0x77154d11 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x7718dca9 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
#2 0xaa43fb20 in ?? ()
#3 0x7718dc70 in ntdll!DbgUiIssueRemoteBreakin () from C:\WINDOWS\SYSTEM32\ntdll.dll
#4 0x7556fa29 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#5 0x77147a7e in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#6 0x77147a4e in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#7 0x00000000 in ?? ()

Thread 1 (Thread 3240.0xfc4):
#0 0x77152a1c in ntdll!ZwWriteFile () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1 0x7509f32c in WriteFile () from C:\WINDOWS\System32\KernelBase.dll
#2 0x00000134 in ?? ()
#3 0x00000000 in ?? ()
(gdb)

不是很有帮助。我不知道下一步该做什么。由于 CrashDebug 的启动方式，我无法断点并单步执行代码以查看问题所在。谁能告诉我如何让这个工作？

标签： gdbcrash-dumpsgdbserver

解决方案

很棒的作者已经（非常迅速地）解决了这个问题。 https://github.com/adamgreen/CrashDebug/issues/18

推荐阅读