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.
Related
This question already has answers here:
How to load program reading stdin and taking parameters in gdb?
(6 answers)
How do I pass a command line argument while starting up GDB in Linux? [duplicate]
(4 answers)
Closed 9 years ago.
often i see some gdb guide using examples without parameters. But in parctice, i need to gdb debug a programe with parameters.
this program is run as "./voronoi -t outputfile", -t is programme voronoi itself parameter, is input, and outputfile is outputfile. but when i using "gdb ./voronoi -t outputfile", it will tell me some error, but when using no gdb debug, run "./voronoi -t outputfile" is OK.
How make it both can gdb debugging and aslo with parameters? How to set the parameters?
You may want to take a look at the run and start commands of gdb—you can pass them the commandline parameters just like you are used to at the shell prompt:
% gdb my_program
[...]
start par1 par2 par3 ...
$ gdb program
break linenumber|functionName
run [parameters]
if your system is windows,you can do this:
1.gdb your_program
2.set args para1 para2 para3...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I wrote a shell in C. There are some problems while running some programs on it.How can I run a program on a shell while debugging the shell in the gdb?
First use -g option to compile with debugging flags, for use with gdb.
Then run.
gdb shellapp
...
run someapps
...
For a quick reading How to Debug C Program using gdb in 6 Simple Steps and GDB Tutorial
Or do you mean run a program in the background?
You can attach by gdb to already running shell process from another console. This way your shell output will not interfere with gdb output and you can run programs in shell as usual.
Run your implementation of shell in 1st console window
Open 2nd console and find pid number of already running shell using ps command
Start gdb in 2nd console and attach to shell using it's pid number like this:
:~$ gdb -q
(gdb) attach 3479
Attaching to process 3479
Now you can set breakpoints and continue shell execution:
(gdb) b SomeFunction
(gdb) c
Continuing.
From this point you have 2 consoles:
the one where your shell is running
and the second where gdb runs attached to shell
You can use shell as usual: run other programs on it or do whatever else. And at the same time you can observe shell execution in 2nd console inside gdb. The point is that output of these 2 processes are separated from each other which would be impossible if you run shell directly inside gdb in just one console.
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.
I run a program with LD_PRELOADing a specific library. Like this.
LD_PRELOAD=./my.so ./my_program
How do I run this program with gdb?
Do the following.
gdb your_program
(gdb) set environment LD_PRELOAD ./yourso.so
(gdb) start
Posting because we ran into a case where set environment didn't work:
From GDB documentation:
set exec-wrapper wrapper
show exec-wrapper
unset exec-wrapper
When ‘exec-wrapper’ is set, the specified wrapper is used to launch programs for debugging. gdb starts your program with a shell command of the form exec wrapper program. Quoting is added to program and its arguments, but not to wrapper, so you should add quotes if appropriate for your shell. The wrapper runs until it executes your program, and then gdb takes control.
You can use any program that eventually calls execve with its arguments as a wrapper. Several standard Unix utilities do this, e.g. env and nohup. Any Unix shell script ending with exec "$#" will also work.
For example, you can use env to pass an environment variable to the debugged program, without setting the variable in your shell's environment:
(gdb) set exec-wrapper env 'LD_PRELOAD=libtest.so'
(gdb) run
A way to set both the environment and arguments in one command:
gdb --args env LD_PRELOAD=/usr/local/lib/libstderred.so /usr/bin/ls -l
This uses env to the same effect as an exec wrapper (like Alexey Romanov's answer), except that GDB doesn't know about it. The side effect is that your session will start in env. Fortunately, GDB will follow the exec into the target program as if nothing happened, and the backtrace is identical.
The convenience of having everything in one command is that your shell history will help you run the exact same thing again.
You can supply env as an exec-wrapper on the command line using the -iex flag:
gdb -iex "set exec-wrapper env LD_PRELOAD=./my.so" ./my_program
I am using gdbserver with VS Code, the simplest way is launching your program wrapped in a shell:
gdbserver :8888 sh -c 'LD_PRELOAD=/libtest.so your_prog'
You can basically do it the same way, just add gdb before the program name:
LD_PRELOAD=./my.so gdb ./my.program
You can check the environment variables using:
(gdb) show environment LD_PRELOAD
In the rare case you actually need to change it inside gdb, e.g. when debugging a dlopen(), you ca do that:
(gdb) set environment LD_PRELOAD ./my.so
Oh, wait, it doesn't work for me with gdb 7.6.2! The library doesn't get loaded, that means none of the answer here are entirely correct, at least with current tools.
I have been asked in an interview how can you debug segmentation fault in C program using GDB.
I told them we can compile our program with -g option so as it add debugging information to binary file and can read core dump file but then interviewer told me if he we have 3 to 4 files compiled together but one of them causing segmentation fault then how do we debug in GDB?
$ gcc -ggdb s1.c s2.c s3.c -o myprog
$ gdb myprog
(gdb) run --arg1 --arg2
GDB will run the program as normal, when the segmentation fault occurs GDB will drop back to its prompt and it will be almost the same as running GDB with a core file. The major difference is there are some things you cannot do/print with a core file that you can when the program has crashed inside of GDB. (You can use print to call some functions inside the program, for example.)
You can also attach to an already running program using gdb --pid <the programs pid>.
Either with a core file or with one of the methods above, when you have the GDB prompt after the crash, type backtrace (or bt for short) and GDB will show you the stack at the time of the crash, including the file names and line numbers of each call and the currently executing line.
If you are working under Linux the easier way to find segmentation fault is by using the tool named VALGRIND: http://valgrind.org/ .
You just need to compile your code with -g flag and then run ./valgrind .
Then you will know exactly in which function and in which line of code there is an error-uninitialized memory/memory read out of allocated space or sth.
You just run the program under gdb, and the debugger with catch the SIGSEGV and show you the line and instruction that faulted. Then you just examine the variable and/or register values to see what's wrong. Usually it's a rogue pointer value, and trying to access it with GDB will give and error, so it's easy.
And yes, recompiling everything with -g would be helpful. The interviewer probably wanted you to describe how you'd figure out which file had the fault (gdb just tells you when it catches the signal) and just recompile that one with debug info. If there's 20,000 source files that might be useful, but with 3 or 4 files, what's the point? Even with larger projects, you usually end up chasing the bad pointer through 10 functions and 5 files anyway, so again, what's the point? Debug info doesn't cost anything at run time, although it costs disk space in an installation.
compile the code in normal way by giving gcc filename
you will get a .out file, start running that and get the process id by giving ps -aef | grep filename.out
in a another window type gdb and enter,inside gdb prompt give attach processid (processid you will get from above command),give c to continue.once the execution finishes give "bt" inside gdb.you will get the place where the segmentation is occurring.
Sounds like they are looking to set it up so that you can step through the code as it is running, you can do this with the command line version or I think you can get a GUI for GDB.
one can use the following steps to debug segmentation fault using gdb
$ gdb <exec name >
$ r //run the pgm
$ where
$ f <1> <0> //to view the function n variables
$ list
$ p <variable>