Open likewise opened 3 years ago
Also see #195 which might be related.
I tried to reproduce this by hacking my source to return ERROR_FAIL at the same point, with the result being that OpenOCD exits when it encounters the failure. This sounds like a problem that has been addressed in riscv-openocd already, but that has not been merged upstream yet.
@likewise, we do intend to upstream and align this repository with mainline OpenOCD. However, currently RISC-V OpenOCD is almost on top of mainline (the mainline version used is about a week old). Please, consider using RISC-V OpenOCD for now if you are connecting to RISC-V targets. On this note, can you please check if the issue is present in RISC-V OpenOCD?
I am running an unstripped OpenOCD 0.11.0 (release version) build inside GDB to provide info about a segfault that occurs when OpenOCD is resetting a RISC-V target that is in an unknown corrupt state. (I am not sure if this bug report belongs at riscv/riscv-openocd or at mainline openocd, I am starting here).
The target is a RISC-V, a variation of the lowRISC Ibex simple_system running on a Xilinx FPGA, DMI via BSCANE2.
In very rare cases I get that target into a condition where OpenOCD can be segfaulted. This bug report is about the OpenOCD segfault.
At this point OpenOCD is waiting for any connection. From another terminal I run
telnet localhost 4444
and inside that telnet session I type
reset
OpenOCD now additionally mentions "Hart 0 doesn't exist." then segfaults:
Here is a further backtrace (OpenOCD was probably compiled with optimizations, a default build)
https://sourceforge.net/p/openocd/code/ci/v0.11.0/tree/src/target/register.c#l107
Aparently target->reg_cache is NULLified somewhere for this situation, and there is no safe-guarding against target->reg_cache == NULL which causes the segfault:
While my RISC-V target is in this rare condition I will rebuild OpenOCD as unoptimized unstripped for more debugging.