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>
Related
When I hit a breakpoint in GDB, and I need to find out what thread this is on, I do info thr. This prints out the list of all the threads in my program, and the current thread is marked with a *
Instead of having GDB dump the entire list of threads, and then manually reading what thread has the *, is there a command in gdb which simply prints out the current thread?
I need this because I am logging some behavior in my program. In other words, I have something like this -
(gdb) command 12
>> p " xyz just happpened"
>> whatThreadIsThis // I would like this
>> c
>> end
If GDB implemented something like the whatThreadIsThis command, then I could use GDB to log all occurrences of xyz with the threads they happened on.
You can use the "thread thread-id" command to switch to another thread as the docs mentions. What the docs doesn't seem to mention is that without any argument, it just prints the current thread:
(gdb) thread
[Current thread is 1 (Thread 0x7ffff7fc2700 (LWP 4641))]
gdb also has Convenience Variables.
One of the them is:
$_thread
The thread number of the current thread.
You can print it with:
(gdb) p $_thread
$2 = 2
Also it can be used in conditions:
condition 1 $_thread != 1
This question already has an answer here:
How to find which thread caused SEGFAULT in a post-mortem gdb session?
(1 answer)
Closed 8 years ago.
My application uses more than 8 threads. When I run info threads in gdb I see the threads and the last function they were executing. It does not seem obvious to me exactly which thread caused the SIGSEGV. Is it possible to tell it? Is it thread 1? How are the threads numbered?
When you use gdb to analyze the core dump file, the gdb will stop at the function which causes program core dump. And the current thread will be the murder. Take the following program as an example:
#include <stdio.h>
#include <pthread.h>
void *thread_func(void *p_arg)
{
while (1)
{
printf("%s\n", (char*)p_arg);
sleep(10);
}
}
int main(void)
{
pthread_t t1, t2;
pthread_create(&t1, NULL, thread_func, "Thread 1");
pthread_create(&t2, NULL, thread_func, NULL);
sleep(1000);
return;
}
The t2 thread will cause program down because it refers a NULL pointer. After the program down, use gdb to analyze the core dump file:
[root#localhost nan]# gdb -q a core.32794
Reading symbols from a...done.
[New LWP 32796]
[New LWP 32795]
[New LWP 32794]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./a'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6
(gdb)
The gdb stops at __strlen_sse2 function, this means this function causes the program down. Then use bt command to see it is called by which thread:
(gdb) bt
#0 0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6
#1 0x00000034e4268cdb in puts () from /lib64/libc.so.6
#2 0x00000000004005cc in thread_func (p_arg=0x0) at a.c:7
#3 0x00000034e4a079d1 in start_thread () from /lib64/libpthread.so.0
#4 0x00000034e42e8b6d in clone () from /lib64/libc.so.6
(gdb) i threads
Id Target Id Frame
3 Thread 0x7ff6104c1700 (LWP 32794) 0x00000034e42accdd in nanosleep () from /lib64/libc.so.6
2 Thread 0x7ff6104bf700 (LWP 32795) 0x00000034e42accdd in nanosleep () from /lib64/libc.so.6
* 1 Thread 0x7ff60fabe700 (LWP 32796) 0x00000034e4281451 in __strlen_sse2 () from /lib64/libc.so.6
The bt command shows the stack frame of the current thread(which is the murder). "i threads" commands shows all the threads, the thread number which begins with * is the current thread.
As for "How are the threads numbered?", it depends on the OS. you can refer the gdb manual for more information.
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)
I've run into some problems debugging a multi-threaded process using GDB. I have a multi-threaded process that splinters off into several (8 or 9) different threads, and I am trying to determine what the contents of variables are when the constructor for a class called XML_File_Data is called. However, I've run into a problem where, after I apply the correct function breakpoint to all threads and it's apparent one of the thread's break point is getting hit (the program temporarily halts execution), I'm not able to determine which thread hit the breakpoint. The command
(gdb) thread apply all where
is giving me shockingly useless information in the form:
#0 0x004ab410 in __kernel_vsyscall ()
#1 0x05268996 in nanosleep () from /lib/libc.so.6
#2 0x052a215c in usleep () from /lib/libc.so.6
#3 0x082ee313 in frame_clock_frame_end (clock=0xb4bfd2f8)
at frame_clock.c:143
#4 0x003a349a in ?? ()
#5 0x00b5cfde in thread_proxy ()
from /cets_development_libraries/install/lib/libboost_thread-gcc41-mt-1_38.so.1.38.0
#6 0x02c1f5ab in start_thread () from /lib/libpthread.so.0
#7 0x052a8cfe in clone () from /lib/libc.so.6
Of the 9 processes, 7 or so are giving me almost exactly that output, and the information about the last 2 isn't really much more helpful (functions far down the call stack have recognizable names, but any recent #0-#4 functions aren't recognizable).
This is what I have so far:
(gdb) gdb
(gdb) gdb attach <processid>
(gdb) thread apply all 'XML_File_Data::XML_File_Data()'
and (after the breakpoint is hit)
(gdb) thread apply all where
Could any experienced debuggers offer me some hints on what I am doing wrong or what is normally done in this situation?
Cheers,
Charlie
EDIT: Fortunately, I was able to find out that the cause of the ??'s was optimized code being run through the debugger, in addition to not running the debugger in the directory of the executable file. Still not much success with the debugging though.
I find myself doing this all the time:
> t a a f
Short for:
> thread apply all frame
Of course, other variants are possible:
> t a a bt 3
Which prints the bottom 3 frames of each thread's stack. (You can also use negative numbers to get the top N frames of the stack)
You can use command thread or info threads to find out the current thread number after breakpoint hit
(gdb) thread
[Current thread is 1 (Thread 0xb790d6c0 (LWP 2519))]
(gdb)
(gdb) info threads
17 Thread 0xb789cb90 (LWP 2536) 0xb7fc6402 in __kernel_vsyscall ()
16 Thread 0xb769bb90 (LWP 2537) 0xb7fc6402 in __kernel_vsyscall ()
15 Thread 0xb749ab90 (LWP 2543) 0xb7fc6402 in __kernel_vsyscall ()
14 Thread 0xb7282b90 (LWP 2544) 0xb7fc6402 in __kernel_vsyscall ()
13 Thread 0xb5827b90 (LWP 2707) 0xb7fc6402 in __kernel_vsyscall ()
12 Thread 0xb5626b90 (LWP 2708) 0xb7fc6402 in __kernel_vsyscall ()
11 Thread 0xb5425b90 (LWP 2709) 0xb7fc6402 in __kernel_vsyscall ()
10 Thread 0xb5161b90 (LWP 2713) 0xb7fc6402 in __kernel_vsyscall ()
9 Thread 0xb4ef9b90 (LWP 2715) 0xb7fc6402 in __kernel_vsyscall ()
8 Thread 0xb4af7b90 (LWP 2717) 0xb7fc6402 in __kernel_vsyscall ()
7 Thread 0xb46ffb90 (LWP 2718) 0xb7fc6402 in __kernel_vsyscall ()
6 Thread 0xb44feb90 (LWP 2726) 0xb7fc6402 in __kernel_vsyscall ()
5 Thread 0xb42fdb90 (LWP 2847) 0xb7fc6402 in __kernel_vsyscall ()
4 Thread 0xb40fcb90 (LWP 2848) 0xb7fc6402 in __kernel_vsyscall ()
3 Thread 0xb3efbb90 (LWP 2849) 0xb7fc6402 in __kernel_vsyscall ()
2 Thread 0xb3cfab90 (LWP 2850) 0xb7fc6402 in __kernel_vsyscall ()
* 1 Thread 0xb790d6c0 (LWP 2519) 0xb7fc6402 in __kernel_vsyscall ()
(gdb)
An asterisk `*' to the left of the gdb thread number indicates the current thread. See here.