I started a Centos process which has been running for several hours now. I used gcc -g to build the shared library and executable. I started the gdb process by entering gdb ./MatchUpAccurate. Once gdb starts, I enter run -input XXXXXXX -fileloc YYYYY -version 5.
When I enter ps -ef, I see two process id numbers, one for gdb ./MatchUpAccurate.exe and another one for ./MatchUpAccurate.exe -input XXXXXXX -fileloc YYYYY -version 5.
Since the child process has been running for several hours now, I would like attach to it so I can check the value of its variables and to see what instruction it is running currently.
I read some documentation an how to use gdb to attach an already running process. However all the examples have no command line arguments. I was wondering how to use gdb to attach a process with command line arguments. I would to be able to set breakpoints, inspect variable, look at the call stack, and step through the execution path without killing the original process. Thank you.
you need to attach to the pid:
gdb binary_name pid
alternatively, start gdb and attach
user#host ~> gdb binary_name
(gdb) attach 1234
If you start your exe with gdb you do not have to attach to it. Just hit Ctrl-C and have a look at your variable.
If you want to attach, start your exe :
./myexe --myopt myargs
get the pid :
myexe_pid=$!
Then attach :
gdb ./myexe $myexe_pid
my2c
Related
I have a daemon (say tempd) running and gdb is attached to it.
% ps x | grep tempd
5467 ?? S 0:00.36 /usr/sbin/tmpd -N
> gdb
gdb> symbol-file /var/tmp/tmpd
gdb> attach 5467
gdb> breakpoint a_funcion_name
breakpoint was set
gdb> c
continuing
.
How can make gdb to automatically attach to the new PID when the daemon restarts? I want to set the breakpoint at a function which gets executed before I find the daemon's new PID and attach gdb to it manually. I do not have the option to start the daemon from within gdb, as it is triggered by an event.
Is it your own daemon? If so, can start gdb from within the daemon?
system( "xterm -c gdb <prog-path> <pid> &");
should do the trick. Maybe add a sleep afterwards to give xterm/gdb time to come up.
You could create another script, that check's constantly or in an inerval
If a process named x is created
Then execute gdb and attach to it.
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
I am a beginner and got some trouble in RE.
I have an ELF 'bomb' and an unknown file 'model.abc'.
The correct way to run bomb is:
bomb model.abc
Now I want to use gdb to see the value of some addresses when running it. Can any one help me?
First start gdb from a shell prompt:
$ gdb bomb
Then run your program from the (gdb) prompt with the command line you want:
(gdb) run model.abc
You need to launch your program this way because gdb doesn't allow you to specify command line arguments for your program on the gdb command line.
Another, more convenient way of debugging a program with arguments:
gdb --args program <arguments>
If you don't have symbols, you'll have to start from the entry point. To figure our where it is, use:
(gdb) info file
Symbols from "/.../tesprog".
Local exec file:
`/.../tesprog', file type elf32-i386.
Entry point: 0x804abc0
Then you can set breakpoint on it before running:
break *0x804abc0
Note that the entry will be most often the library startup code (ctr0.s), it might take a while to get to the actual code written by the programmer.
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.
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