Let say I want to debug 2 instances of my program "Program.exe", each one with a different argument ("one" and "two"). Also I need to run both process at the same time (or at least within 1 second).
I've read that GDB's inferiors lets you run and debug multiple programs in a single session. And this is my try:
file Program.exe
set args one
add-inferior
inferior 2
file Program.exe
set args two
run
But not success. Only one inferior is running
Any idea?
I'm considering these two options:
Creating a new program that forks the process, then GDB can handle both processes through "set detach-on-fork off" but this approach seems to me a bit ugly...
Launching two processes normally and then attach them by PID in GDB. But my environment is Windows and I don't know how to do that nor how to find PID by command line argument.
Thanks in advance!
Related
I'm trying to achieve the "Semihosting" like feature by registering a set of commands associated with a specific break point, like:
print buffer[0]
cont
So the plan is having analog values dumped into the GDB client console in realtime, thus making the development process easier.
Is it possible for GDB to execute above example commands when the breakpoint on line 38 (eg.) is hit? (I will need to run different set of commands on another break point)
Each breakpoint you add in gdb has a number. You can see the numbers with i b (short for info breakpoints). Suppose you want to add commands to breakpoint number 2, just type commands 2 and press ENTER. Now, type the commands you want gdb to run when breakpoint 2 is hit (one per line). When you want to finish entering the commands, type end.
Tip: You can add the continue command before end if you want gdb to continue execution instead of stopping. That is, if you only added to breakpoint to add commands to it but you don't want execution to stop there. For instance, if you just want to print the value of some variable, or even if you want to create another breakpoint but only if some specific code path is reached first. The possibilities are endless.
got some big real time project to deal with (multiple processes (IPCs), multi Everything in short).
My working on process is started as service on Linux. I have the root access.
Here is the problem:
I'm trying to attach to a running proc, tried starting it through/with gdb but the result is the same: it stops the executable once I "touched" it with gdb or sometimes it throws:
Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x7f9fe869f700 (LWP 2638)]
of course from there nothing can be done.
Tried:
handle all nostop
attach to launched as service (daemon) or launched as regular proc
started from gdb
thought maybe forking/multi-threaded problem - implemented in the very beginning sleep for 10 seconds - attached to it with "continue"
Guys, all I want it is to debug, hit the breakpoints, etc.
Please help! Share ideas.
Editing actual commands:
1) gdb attach myProcId. Then after reading symbols, I hit "c" which results:
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7f9fe869f700 (LWP 2638)]
0x00007f9fec09bf73 in select () from /lib64/libc.so.6
2) If I make the first line 10 seconds sleep in the code, attaching to the process, hit "c", result: it runs, shows info threads, backtrace of main, but never hits the breakpoint (for sure the code runs there - I get logs and different behaviour if I change code there), meaning the process is stuck.
3) All other combinations like gdb path/to/my/proc args list, then start. Where arg list played with different related options gdb gives us.
Maybe worth to mention: process network packets related, timers driven also.
But for me the important thing is a current snapshot on break, i don't care what will happen to the system after timers expired.
Since you mentioned that you are debugging a multiprocessing program, I think the underlying program you have is to set the breakpoint in the correct subprocess.
Try break fork and set follow-fork-mode child/parent. What you want to achieve is have gdb attached to the process that is running the code you want to debug.
Refer to this link.
Another thought is to generate a crash, since you can compile the programe. For example add a int i = *(int*)NULL and that will generate a core dump. You can then debug the core dump with gdb <program> <core dump>. You can refer to this page for how to configure core dump.
I'm debugging a C++ application which creates trees of forks. Using GDB defaults, the child processes will be detached on the fork and as a result I see only one inferior shown afterwards.
I tried to attach to one of the child processes and despite it not being listed as an inferior for the other GDB process, in the new GDB session I get an error that the process is already being traced (by the first GDB session).
Is this expected behavior? What steps can I take to debug the forked process in a separate GDB session? What steps can I take to debug the problem further?
I attached to my multithread application with gdb and after that type cont to continue execution.
Is there any way to stop execution at any time on cont gdb state and check what every thread do?
How to check state of every thread and get execution line number of each? (commands)
Here's what I do, (taken from here )
Create a little gdb script stackdumper.gdb that dumps the stack trace of all threads:
thread apply all backtrace
Then repeatedly attach gdb and run the dumper:
for i in $(seq 1 10) ; do
gdb -batch -x stackdumper.gdb ./a.out 123456 > stack.$i
sleep 10
done
where ./a.out is the binary you are interested and 123456 is the PID.
Adjust the sleep to match your sampling needs.
thread apply all bt
Or
info threads
t <threadid from above trace >
Followed by
where or bt
To get the backtrace for all of the stopped threads type the
thread apply all bt
command (the output is exactly the same that one might see in the MacOSX crash report box).
Usually the threads are stopped simultaneously in gdb.
Reference: http://www.delorie.com/gnu/docs/gdb/gdb_40.html
And here's about "all-stop" mode, which is default: http://sourceware.org/gdb/onlinedocs/gdb/All_002dStop-Mode.html
Is this any way to stop execution at any time on cont gdb state and check what every thread do
If you ask about ways to check what threads do without gdb the you can just run pstask <pid-of-your application>
Is it "pstack" because i don't think "pstask" is any command in linux, If it is please provide some more info
Without getting into to to much detail, I'm working on a program that consists of several separate processes all running on embedded QNX RTOS. They don't have a parent-child relationship, they are all spawned using spawnlp(P_NOWAIT, ...) and they all communicate with each other using the IPC mechanism provided by the OS.
When I'm debugging with GDB and I hit a breakpoint in the process I'm working in, all of my threads are paused, which is great. But is there a way to also have it pause execution of my other processes? Right now what's happening is all the other processes keep on truckin' while my process is paused and so all the IPC queues get full etc. etc.
Thanks in advance,
HF
You can associate a list of GDB commands with each breakpoint. So when you hit a breakpoint in process A, you can for example send a SIGTRAP to process B, which should drop it into the debugger:
(gdb) b main
Breakpoint 1 at 0x804834a: file testA.c, line 40.
(gdb) command
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>shell kill -s TRAP `pidof testB`
>end
(gdb)
More info at Breakpoint Command Lists