I am trying to debug two instances of the same application. Therefore I setup as followed:
(gdb) set target-async on
(gdb) set non-stop on
(gdb) attach pid1
(gdb) set scheduler-locking off
(gdb) add-inferior
(gdb) inferior 2
(gdb) attach pid2
(gdb) set scheduler-locking off
(gdb) b hello-world.cpp:8
Breakpoint 1 at 0x557a557761fd: ../hello-world.cpp:8. (2 locations)
(gdb) continue
The Problem I have is that only the currently selected inferior is continued. Is there a way to let all inferiors continue with one command?
Solution:
It works if the following sequnce is used:
(gdb) attach pid1
(gdb) add-inferior
(gdb) inferior 2
(gdb) attach pid2
(gdb) set schedule-multiple on
(gdb) b hello-world.cpp:8
Breakpoint 1 at 0x557a557761fd: ../hello-world.cpp:8. (2 locations)
(gdb) continue
Thanks to Klaus!
To continue all attached processes you have to set the scheduler mode in gdb.
set scheduler-locking off
A continue now let all threads continue.
For a detailed description of scheduler mode take a look here
As you ask in the comments what the complete procedure was:
(gdb) attach <pid 1>
(gdb) add-inferior
(gdb) inferior 2
(gdb) attach <pid 2>
(gdb) set scheduler-locking off
(gdb) b myprog.cpp:55
Related
gdb switches a thread when the appropriate breakpoint fires.
I need to remember the thread number to come back with thread n.
Is there a special command to return to the thread where step-by-step execution was performed?
(gdb) n
57 m_app = create_app();
(gdb) n
[Switching to Thread 0x7fffdfffd700 (LWP 32059)]
Thread 9 "foo" hit Breakpoint 1, 0x0000000000421ef0 in App::App()#plt ()
(gdb) # command to return to the interrupted thread
You can setup custom GDB prompt to show current thread number with set extended-prompt:
(gdb) set extended-prompt <\t>
Every time you use any of GDB commands current thread number will be printed in GDB prompt, for example:
<1> thread
[Current thread is 1 (Thread 0x7ffff7dcd740 (LWP 148411))]
<1> info threads
Id Target Id Frame
* 1 Thread 0x7ffff7dcd740 (LWP 148411) "a.out" main () at /home/ks/t.c:7
<1>
With that information in GDB prompt you can return to interrupted thread with:
thread <id_taken_from_prompt_before_interrupt>
Why is GDB not able to see my local variable i ?
I am debugging a multi-process application running on an embedded linux device.
I am having a hard time attaching to a child process (note that I cannot start the child process by itself, it needs the parent to run it. )
Using set follow-fork-mode child did not work (gdb hangs while loading dynamic libraries).
My strategy is to have this in my code to stop the child
#ifdef DEBUG
int i = 0;
while (i == 0)
{
usleep(100000); // sleep for 0.1 seconds
}
#endif // DEBUG
To have time to attach to the child using gdbserver --attach :1234 <child-pid> and then, after setting a break point where I want (line 200 in main.cpp), to issue the following command in gdb : set var i = 1 to break out of the while loop.
This isn't working and I am wondering why. Here is the output from gdb:
(gdb) bt
#0 0x00007ff3feab7ff0 in nanosleep () from target:/lib/libc.so.6
#1 0x00007ff3feae1c14 in usleep () from target:/lib/libc.so.6
#2 0x000055cc4e56908a in main (argc=<optimized out>, argv=<optimized out>)
at platform/aas/intc/ucmclient/src/main.cpp:195
(gdb) break main.cpp:200
Breakpoint 1 at 0x55cc4e56908c: file platform/aas/intc/ucmclient/src/main.cpp, line 200.
(gdb) set var i=1
No symbol "i" in current context.
The backtrace seems to show I am in the while loop. Why then is the variable i not in the locals?
I'm using STM32H745ZI Nucleo board with STLinkV3. I have successfully compiled and run simple program that flashes LEDs on Cortex M7 core. When program runs without debugger, everything's fine.
The problem appears while degugging. When I set breakpoint on line that turns the LED on, debugger stops in this place. The problem is that once stopped, continue and step over aren't working until the breakpoint is unset.
Code isn't much complicated:
while (1) {
LD1_SET(1);
HAL_Delay(100);
LD2_SET(1);
HAL_Delay(100);
LD3_SET(1);
HAL_Delay(100);
LD1_SET(0);
HAL_Delay(100);
LD2_SET(0);
HAL_Delay(100);
LD3_SET(0);
HAL_Delay(100);
}
This is how it looks like in gdb console:
# Setting breakpoint on LED ON
(gdb) b main.c:166
Breakpoint 1 at 0x8001788: file Src/main.c, line 166.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
# Hit! Debugger seems working, LED is still OFF
Breakpoint 1, main () at Src/main.c:166
166 LD1_SET(1);
(gdb) c
Continuing.
# Hit the same breakpoint with no blinking between
Breakpoint 1, main () at Src/main.c:166
166 LD1_SET(1);
# Setting breakpoint on LED OFF
(gdb) b main.c:174
Breakpoint 2 at 0x80017c6: file Src/main.c, line 174.
(gdb) c
Continuing.
# Still hits LED ON, LED is still OFF
Breakpoint 1, main () at Src/main.c:166
166 LD1_SET(1);
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x08001788 in main at Src/main.c:166
breakpoint already hit 3 times
2 breakpoint keep y 0x080017c6 in main at Src/main.c:174
# Removing breakpoint on LED ON
(gdb) del 1
(gdb) c
Continuing.
# LED is ON, prorgram finally hit next breakpoint
Breakpoint 2, main () at Src/main.c:174
174 LD1_SET(0);
How to make it work? Have you experienced similar problem before?
I was writing an little board game which has to add and show an image on a button after clicking on it, and then calling back some other function to show an image on other buttons,but the program didn't run as I think,the widget didn't show until all those functions done.
Here is debug:
Breakpoint 1, GameControl::button_clicked (widget=0x80dad08, data=0x80563e0) at interface.cc:582
582 image = gtk_image_new_from_file ("arrow.bmp");
(gdb) step
583 gtk_container_add (GTK_CONTAINER (widget), image);
(gdb) step
584 gtk_widget_show (image);
(gdb) step
585 computer_move (widget, &control);
(gdb) step
GameControl::computer_move (widget=0x80dad08, data=0x80563e0) at interface.cc:520
520 computer_moving = true;
(gdb) break interface.cc:586
Breakpoint 2 at 0x804cdab: file interface.cc, line 586.
(gdb) continue
Continuing.
Breakpoint 2, GameControl::button_clicked (widget=0x80dad08, data=0x80563e0) at interface.cc:586
586 break;
(gdb) step
593 end_dialog ();
(gdb) next
595 }
(gdb) step
0xb7b1c243 in g_cclosure_marshal_VOID__VOIDv () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
(gdb) step
Single stepping until exit from function g_cclosure_marshal_VOID__VOIDv,which has no line number information.
0xb7b33a29 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
(gdb) next
Single stepping until exit from function g_signal_emit_valist,
which has no line number information.
0xb7b34453 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
(gdb) continue
Continuing.
[Thread 0xb6b86b40 (LWP 7820) exited]
[Thread 0xb61ffb40 (LWP 7821) exited]
[Inferior 1 (process 7817) exited normally]
until the last continue command was executed, the widget shows, for somehow the widget didn't show when it went to "gtk_widget_show ()" , any suggestions?
GTK+, like most GUI toolkits, is event-driven.
You are supposed to return from your callbacks so the main event loop (gtk_main()) can process the next event, otherwise the whole program just freezes.
If you want to process some events half-way through your callback, you do so explicitly. Straight from the docs:
/* computation going on */
while (gtk_events_pending ())
gtk_main_iteration ();
/* computation continued */
I was debugging my app with gdb.
I used break main
So it can break when main is called.
Know if I use thread info it shows that thread count is 1.
How a thread is starting before main ?
I don't have any thread call in my call so from where thread is getting created. I am using these libs
sqlite , curl , pcre , c-client
Update
I have written a sample program to test that if all program start with single thread
#include<iostream>
int main(int argc,char *argv[]){
std:: cout<<"Will I have any thread";
return 0;
}
but when I debug it with gdb
(gdb) break main
Breakpoint 1 at 0x400783: file threadtest.cpp, line 3.
(gdb) run
Starting program: /home/vivek/Desktop/a.out
Breakpoint 1, main (argc=1, argv=0x7fffffffe728) at threadtest.cpp:3
3 std:: cout<<"Will I have any thread";
(gdb) info threads
* 1 process 21608 main (argc=1, argv=0x7fffffffe728) at threadtest.cpp:3
(gdb)
it doesn't show the same information. It show 1 process not 1 thread.
When I compile it with -lpthread it show 1 thread.
So program start with one thread when we use lpthread ?
or GDB behaves like that ?
All programs have at least 1 thread, the main thread. The program is started before main since the C++ runtime does some initializing before main() starts, like calling all global objects which have constructors.
The operating system creates a process space with one thread and calls the application loader to execute the application in that thread, which in turns performs some initial setup (gathering command line arguments into argc and argv, for example) and calls main.
For the sample App when I compile it with -lpthread it shows 1 thread is running.
So lpthread is playing key point here.
(gdb) break main
Breakpoint 1 at 0x400793: file threadtest.cpp, line 3.
(gdb) run
Starting program: /home/vivek/Desktop/a.out
[Thread debugging using libthread_db enabled]
Breakpoint 1, main (argc=1, argv=0x7fffffffe728) at threadtest.cpp:3
3 std:: cout<<"Will I have any thread";
(gdb) info threads
* 1 Thread 0x2aaaaaac8bb0 (LWP 21649) main (argc=1, argv=0x7fffffffe728)
at threadtest.cpp:3
(gdb)