I have a setup with openocd and arm-none-eabi-gdb and I'm trying to debug a FreeRTOS fw.
I start openocd with:
openocd -f /usr/local/share/openocd/scripts/board/stm32f0discovery.cfg -c "stm32f0x.cpu configure -rtos auto"
That command works fine.
Then I run arm-none-eabi-gdb -tui and at the end of my .gdbinit I have:
target remote localhost:3333
monitor reset halt
file build/fw.elf
load
continue
focus next
But when I try to stop <ctrl>-c and start continue my fw all I get is the error:
Cannot execute this command without a live selected thread.
What am I missing?
I'm using a JLink Base debug probe.
My case is a bit different than yours, with a setup using QtCreator and its Baremetal plugin, but found a bug report where they state a workaround:
https://bugreports.qt.io/browse/QTCREATORBUG-18436
The workaround is pretty easy:
in GDB Init commands add "info threads" after load command. It fixes issue.
I tried it, and it worked, the error message was removed, and now I can see the different tasks in FreeRTOS.
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I am remote debugging a Stellaris Launchpad. I use OpenOCD to connect to the stellaris and then connect GDB to the server provided by openOCD. I use Open On-Chip Debugger 0.10.0-dev-00002-g79fdeb3 (2015-07-09-23:28). GDB is the one from arm-gcc-none-eabi, the 4_9-2015q1 release.
I invoke openOCD like this:
/usr/local/bin/openocd --file \
/usr/local/share/openocd/scripts/board/ek-lm4f120xl.cfg \
>> openocdLog.txt 2>&1 &
And then GDB like this:
arm-none-eabi-gdb proj//debug/exec -x gdb//gdb.script
gdb/gdb.script contains:
set remotetimeout 10000
target extended-remote :3333
monitor reset halt
load
monitor reset init
The problem is that whenever I hit control+c GDB disconnects. Normally this would halt the remote, but GDB just disconnects:
(gdb) cont
Continuing.
^CError detected on fd 6
Remote communication error. Target disconnected.: Interrupted system call.
(gdb)
OpenOCD has the following things to say, this one while GDB is launching:
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1258). Workaround: increase "set remotetimeout" in GDB
Which is weird, considering the gdb/gdb.script file forces remotetimeout to an insanly large number.
And when pressing control+c openOCD says:
Debug: 2602 5089 hla_interface.c:119 hl_interface_quit(): hl_interface_quit
So, how do I resolve this? How can I make GDB halt the remote instead of disconnecting when pressing control+c?
The problem was OpenOCD being too bleeding edge. I had issues with 0.6.1, but version 0.7.0 of OpenOCD works great.
I'm having a problem debugging a command line program on OS X. I've used this same source file with the same g++ command line hundreds of times to test things with the Crypto++ library.
Under GDB, I get the following after loading the EXE:
$ gdb ./cryptopp-test.exe
...
(gdb) r
Starting program: /Users/jwalton/cryptopp-test.exe
Unable to find Mach task port for process-id 42811: (os/kern) failure (0x5).
Under LLDB, I get the following:
$ lldb ./cryptopp-test.exe
Current executable set to './cryptopp-test.exe' (x86_64).
(lldb) r
error: initial process state wasn't stopped: exited
I've recompiled the program a few times, and I can't get it to run under a debugger. I'm getting a segfault when trying to run outside the debugger too, so that may be a symptom here also.
OS X is 10.8.5, and Xcode is 5.1.1 (5B1008). Everything is fully patched. The only thing to change recently is signing up for a developer account, which is broken thanks to Apple's DRM crap. I can't seem to get any of it to work with Xcode or the command line even though Roots and Certificates are in my Keychain. But this program does not use code signing.
What is causing the initial process state wasn't stopped: exited error, and how do I fix it?
The errors that you have received are usually a direct correlation of a codesigning issue, not with your executable, but with gdb and lldb themselves.
You have a couple of options:
Launch gdb or lldb as sudo (which ignores the codesign req to run executables)
Create a codesigning certificate for gdb or lldb in Keychain.app
Obviously the first option is quickest, but probably should be avoided as it opens up the possibility of bad things happening with elevated permissions.
With option #2 you can likely get gdb or lldb properly working by doing this:
Launch /Applications/Utilities/Keychain Access.app
Select the Keychain Access -> Certificate Assistant -> Create a Certificate...
Choose a name for the new certificate (for example lldb-cert or gdb-cert)
Set Identity Type to Self Signed Root
Set Certificate Type to Code Signing
Select the Let me override defaults option
Continue until the "Specify a Location For The Certificate" screen appears
Set Keychain to System and Continue
In the view showing your certificates, double-click on the one just created and then set "When using this certificate" to "Always Trust"
In Terminal:
codesign -f -s "gdb-cert" /path/to/gdb (or) "lldb-cert" /path/to/lldb
You might have to restart for this to effectively take hold.
There are more concise instructions here for gdb and here for lldb on the codesigning process.
I'm using GDB and OpenOCD to debug a simple program on my STM32F4DISCOVERY board on Windows. This works fine when starting OpenOCD separately, and using TCP/IP to connect to it, with something like this:
target remote localhost:3333
When I'm done, I can shut down GDB using quit as normal. I would like, however, to use GDB in "remote pipe" mode, instead of needing to start and stop OpenOCD manually. This seems like a somewhat ideal configuration to me. When I do this, however, I cannot exit GDB, as it hangs when I attempt to exit.
The OpenOCD log file shows that the GDB connection was dropped:
Info : dropped 'gdb' connection
But GDB never exits:
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be detached.
Quit anyway? (y or n) y
Detaching from program: yagarto_sample.elf, Remote target
Ending remote debugging.
The disconnect command similarly hangs, never returing. Not even Ctrl-C will wake up GDB.
It turns out there is a bug in OpenOCD related to a change made by GDB. A bit of detail is here, and a patch has been submitted, and a workaround is provided:
Add this to your cfg:
$_TARGETNAME configure -event gdb-detach { shutdown }
I tested this workaround, and it does work, but in the end, pipe mode is so slow on Windows that I chose to use TCP, even though it is less convenient.
I'm trying to debug a server I wrote with gdb as it segfaults under very specific and rare conditions.
Is there any way I can make gdb run in the background (via quiet or batch mode?), follow children (as my server is a daemon and detaches from the main PID) and automatically dump the core and the backtrace (to a designated file) once the program crashes?
Assuming you have appropriate permissions, you can have gdb attach to any process. You can do it on the command line with:
gdb /path/to/binary _pid_
or from within gdb with the attach command:
attach _pid_
So, once your daemon has started, you can use either of these techniques to attach to the final PID your daemon is running as. Attaching gdb stops the process which you are tracing so you will need to issue a "continue" to restart it.
I don't know a direct way to get gdb to run arbitrary commands when the program crashes. Here is one workaround I can think of:
Create and register a signal handlers for SIGSEGV.
Tell gdb not to stop on that signal (handle SIGSEGV nostop)
Set a breakpoint at the first line of your signal handler.
Assign commands to the breakpoint from step 3
Why not just run the process interactively in a persistent screen session? Why must it be a daemon when debugging? Or just run gdb in the screen session and attach it to the running process (e.g. gdb /path/to/binary -p PID_of_binary) after it forks.
First, I'd setup your shell / environment to give you a core dump. In bash:
ulimit -c unlimited
Once you have the core dump, you can use gdb to examine the stack trace:
gdb /path/to/app /path/to/core/file
I'm not really a gdb expert but two things come to mind
Tracepoints which might give you the necessary information as your program runs or
Use gdb's remote debugging facility to debug your program while it's running as a daemon.
How to generate a stacktrace when my gcc C++ app crashes answer for this question should do what you want. (assuming you can make changes in your code)
You might want to take a look at how Samba facilitates debugging; it has a configurable "panic action" that can suspend the application, notify the developer, spawn gdb, etc., and is run as part of its signal handler. See lib/util/fault.c in the Samba source tree.
My practice: comment out daemon function call, rebuild binary, then use gdb to run.