I'm trying to run my program TestApc via gdb and get useful data when my program crash with back trace command ("bt" command).
I wrote a bash script , which look like:
#!/bin/bash
gdb -ex=r --args ./TestApc
When the program crash, I can't type the "bt" command (because I get out from the gdb console)
Is there a way to stay on gdb after the crash ?
Related
When running my program, I am getting Gtk-CRITICAL error on the Terminal, which I'd like to fix.
I found this link through Google, but turns out there is no such option in gdb:
igor#IgorReinCloud ~/dbhandler/Debug/dbhandler $ gdb --g-fatal-warnings dbhandler
gdb: unrecognized option '--g-fatal-warnings'
Use `gdb --help' for a complete list of options.
I also tried to set a breakpoint on the g_log() function, but the execution didn't stop there.
What am I missing?
Thank you.
you can use G_DEBUG=fatal-criticals, so that the application execution breaks at the first location where a critical is emitted.
To run inside gdb, run G_DEBUG=fatal-criticals gdb my-app, and as usual, do run inside gdb to run your application.
You may also set the G_DEBUG environment variable with export (if in bash). Thus you could do export G_DEBUG=fatal-criticals, and then run your app as gdb my-app, which will have the same effect.
See https://docs.gtk.org/glib/running.html for more details
What am I missing?
Looks like that after reading the link, you were confused that gdb should have --g-fatal-warnings option for debugging Gtk applications. This is not the case because gdb is not Gtk application, but your program is. So you should run your program with --g-fatal-warnings option inside gdb like this:
gdb --args dbhandler --g-fatal-warnings
See also related question How do I run a program with commandline args using gdb within a bash script?.
This is the Clang version of:
Make gdb quit automatically on successful termination?
How to have gdb exit if program succeeds, break if program crashes?
Running my application many times, programmatically, over a large number of possible inputs, I've occasionally encountered a segmentation fault.
I'd like each test invocation to be run under lldb so that I can get a backtrace for further debugging. If an invocation exits without a crash, I'd like lldb to automatically quit so that the test harness progresses to the next iteration. This way I can set the whole thing off over lunchtime and only have the suite interrupted when something crashes.
Bonus points for having lldb auto-quit in all cases, but first print a backtrace if the program crashed.
I'm currently able to automate at least the initial run command:
lldb -o run -f $CMD -- $ARGS
I'm having difficulty finding an online command reference but it looks like the -batch command line option will get you the basic "exit on success/prompt on fail" behaviour.
For a backtrace and auto-quit on failure I think you need the --source-on-crash option...
-K <filename>
--source-on-crash <filename>
When in batch mode, tells the debugger to source this file of lldb
commands if the target crashes.
So, create the command file with something like...
echo -e 'bt\nquit' > lldb.batch
and then invoke as...
lldb --batch -K lldb.batch -o run -f $CMD -- $ARGS
I am running someone's code and the code crashes on a specific dataset, but the crash message as-is is not informative. I cannot call GDB and then wait (for GDB) to pass r to it (things are running on a cluster). Is there a way to pass r to GDB in the runtime by default, something like the following?
gdb r ./run
You can load your program in GDB, like:
$ gdb your_program_name
and then attach to process which you want to debug
attach pid
You may use a commands file. Write all the commands you want to execute sequentially in the file. And use that file to pass the command to GDB with input redirection:
echo "r" > cmds
gdb r --args ./run -arg1 -arg2 -arg3 < cmds
Whe loading a program with gdb, how do you have gdb automatically start the program and run it without waiting?
Use the -ex command line option and provide the run command.
gdb -ex=r --args executable --with-options-for-the-executable
I'd like to have gdb immediately run the executable, as if I'd typed "run"
(motivation: I dislike typing "run").
One way is to pipe the command to gdb like this:
$ echo run | gdb myApp
But the problem with this approach is that you lose interactivity with gdb,
eg. if a breakpoint triggers or myApp crashes, gdb quits.
This method is discussed here.
Looking at the options in --help, I don't see a way to do this, but perhaps I'm missing something.
gdb -ex run ./a.out
If you need to pass arguments to a.out:
gdb -ex run --args ./a.out arg1 arg2 ...
EDIT:
Orion says this doesn't work on Mac OSX.
The -ex flag has been available since GDB-6.4 (released in 2005), but OSX uses Apple's fork of GDB, and the latest XCode for Leopard contains GDB 6.3.50-20050815 (Apple version gdb-967), so you are out of luck.
Building current GDB-7.0.1 release is one possible solution. Just be sure to read this.
I would use a gdb-script:
gdb -x your-script
where your-script contains something like:
file a.out
b main
r
afterwards you have the normal interactive gdb prompt
EDIT:
here is an optimization for the truly lazy:
save the script as .gdbinit in the working directory.
Afterwards you simply run gdb as
gdb
... and gdb automatically loads and executes the content of .gdbinit.
(echo r ; cat) | gdb a.out
The cat allows you keep typing after gdb breaks.
start command
This command is another good option:
gdb -ex start --args ./a.out arg1 arg2
It is like run, but also sets a temporary breakpoint at main and stops there.
This temporary breakpoint is deactivated once it is hit.
starti
There is also a related starti which starts the program and stops at the very first instruction instead, see also: Stopping at the first machine code instruction in GDB
Great when you are doing some low level stuff.
gdb -x <(echo run) --args $program $args