I am compiling a test case for some code I have written with g++ and trying to debug it with gdb on the command line. The code compiles without errors or warnings, but when I launch my executable with gdb I get the following error:
Assertion failed: (g.numPlayers>0 && g.numPlayers<=MAXPLAYERS && cin), function readScenario, file p3t3.cpp, line 141.
I am using the same exact input arguments with gdb as I am when I run the compiled program normally. Is there a reason something can compile without problems and yet throw an error within gdb?
If you need to pass command-line arguments to your program, then you either need to use
$ gdb --args ./program arg1 arg2
or
$ gdb ./program
...
(gdb) run arg1 arg2
Related
I'm receiving this gdb error on any code I try to debug any program with gdb. Here's the simplest process that reproduces the error
Create a main.cpp file with this content:
int main(){
return 0;
}
Run g++ -g main.cpp
Run gdb a.out
Inside gdb set a break point at line 2 with break 2
In gdb run the program with run
Output:
Starting program: /tmp/test/a.out
During startup program exited normally.
This is all done with gdb on the command line. I've tried using g++ and gcc with the same result. I'm not really sure where to go from here.
gdb version = 9.2
g++ version = 9.3.0
EDIT: I figured out what is causing the issue, but not how to fix it. The issue seems to be something related to my SHELL variable. I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
This might be your xonsh startup problem, or it might be xonsh problem, or it could be that xonsh doesn't do what GDB expects it to do.
Normally, GDB forks / execs $SHELL -c "/path/to/your/exe $args" and expects the $SHELL to exec your program (this is done so shell redirection still works under GDB).
Only after that exec will GDB start setting breakpoints, etc.
If you have some xonsh init-file, which e.g. causes xonsh to exec something else, things could go bad. So I suggest trying to remove any such ~/.xonshrc or whatever it's called file, and seeing whether that fixes the problem.
If it doesn't, it could be that xonsh e.g. forks and execs your binary in a child (grandchild of GDB) instead of doing it directly, or it could be that xonsh doesn't understand the -c ... syntax.
If you don't care about redirection, you could also ask GDB to not use $SHELL at all: set startup-with-shell off. Documentation.
This question already has answers here:
How do I run a program with commandline arguments using GDB within a Bash script?
(9 answers)
Closed 2 years ago.
I have to debug a program that has errors in it as part of my assignment. However, I must first pass command line arguments in order to solve this problem.
I do:
gdb -tui InsertionSortWithErrors
which works, but after that I don't know how to pass arguments. I used gdb -help and it says something about --args which I also tried and it didn't work.
I want to be able to get the debugger+the GUIand pass command line arguments.
Once gdb starts, you can run the program using "r args".
So if you are running your code by:
$ executablefile arg1 arg2 arg3
Debug it on gdb by:
$ gdb executablefile
(gdb) r arg1 arg2 arg3
Try
gdb --args InsertionSortWithErrors arg1toinsort arg2toinsort
Another option, once inside the GDB shell, before running the program, you can do
(gdb) set args file1 file2
and inspect it with:
(gdb) show args
I'm using GDB7.1.1, as --help shows:
gdb [options] --args executable-file [inferior-arguments ...]
IMHO, the order is a bit unintuitive at first.
How can I run something like gdb -e path/to/exe -ex 'run --argnamae argvalue'?
Let's assume a recent version of gfb, within the past year or two.
Gdb runs and prints responses but not interactively.
I think you want gdb --args path/to/exe command line arguments
which will start gdb debugging path/to/exe pass three command line arguments to your exe command, line, and arguments, you can then interact with gdb before issuing the run command.
As for the ImportError: No module named 'libstdcxx' I believe this is already answered here which points to a bug report here.
It appears some versions of GCC have a broken pretty printers python script, you might need to adjust the python sys.path with (gdb) python sys.path.append("/usr/share/gcc-4.8/python"), adjust the path to match whatever GCC version is actually present on your system. You could probably add a command like this to your .gdbinit file to save typing it every time.
How can I run something like ...
You can do this:
gdb path/to/exe -ex 'set args arg1 arg2 arg3'
Or use a shorthand notation for the above:
gdb --args path/to/exe arg1 arg2 arg3
If you want to pass arguments from file,
try this
(gdb) run < the_file_contains_data
When running a program on GDB, usually, the arguments for the program are given at the run command. Is there a way to run the program using GDB and as well as give arguments within a shell script?
I saw an answer in a related question, mentioning that we can attach GDB to the program after the script starts executing. But then I will have to 'wait' the program.
Is there another way to do this?
You can run gdb with --args parameter:
gdb --args executablename arg1 arg2 arg3
If you are doing this often (e.g. when running GDB from a script), you might want to consider the following arguments to automate things further. First, you can place your GDB commands (such as 'run') in a text file and provide the filename to the -x argument. Second, you can have GDB exit after running your commands by providing the --batch argument. A full example:
gdb -x commands.txt --batch --args executablename arg1 arg2 arg3
gdb -ex=r --args myprogram arg1 arg2
-ex=r is short for -ex=run and tells gdb to run your program immediately, rather than wait for you to type "run" at the prompt. Then --args says that everything that follows is the command and arguments, just as you'd normally type them at the commandline prompt.
Another way to do this, which I personally find slightly more convenient and intuitive (without having to remember the --args parameter), is to compile normally, and use r arg1 arg2 arg3 directly from within gdb, like so:
$ gcc -g *.c *.h
$ gdb ./a.out
(gdb) r arg1 arg2 arg3
You could create a file with context:
run arg1 arg2 arg3 etc
program input
And call gdb like
gdb prog < file
If the --args parameter is not working on your machine (i.e. on Solaris 8), you may start gdb like
gdb -ex "set args <arg 1> <arg 2> ... <arg n>"
And you can combine this with inputting a file to stdin and "running immediatelly":
gdb -ex "set args <arg 1> <arg 2> ... <arg n> < <input file>" -ex "r"
In addition to the answer of Hugo Ideler.
When using arguments having themself prefix like -- or -, I was not sure to conflict with gdb one.
It seems gdb takes all after args option as arguments for the program.
At first I wanted to be sure, I ran gdb with quotes around your args, it is removed at launch.
This works too, but optional:
gdb --args executablename "--arg1" "--arg2" "--arg3"
This doesn't work :
gdb --args executablename "--arg1" "--arg2" "--arg3" -tui
In that case, -tui is used as my program parameter not as gdb one.
Much too late, but here is a method that works during gdb session.
gdb <executable>
then
(gdb) apropos argument
This will return lots of matches, the useful one is set args.
set args -- Set argument list to give program being debugged when it is started.
set args arg1 arg2 ...
then
r
This will run the program, passing to main(argc, argv) the arguments and the argument count.
gdb has --init-command <somefile> where somefile has a list of gdb commands to run, I use this to have //GDB comments in my code, then `
echo "file ./a.out" > run
grep -nrIH "//GDB"|
sed "s/\(^[^:]\+:[^:]\+\):.*$/\1/g" |
awk '{print "b" " " $1}'|
grep -v $(echo $0|sed "s/.*\///g") >> run
gdb --init-command ./run -ex=r
as a script, which puts the command to load the debug symbols, and then generates a list of break commands to put a break point for each //GDB comment, and starts it running
If you want to pass arguments from file,
e.g. scanf from a file as input
try this
(gdb) run < the_file_contains_data
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