This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: help debugging multithreaded programs


Hi Ishan,

> When trying to debug a multithreaded application written in C/C++, I
> observed that certain threads which get spawned, exit immediately when
> running the binary through gdb.

One possibility is that your thread is making a system call and
not checking the return value for EINTR (interrupted system call).

Here is the story.  gdb puts invisible internal breakpoints in
certain places in the thread library, such as thread creation and
thread destruction.  When your program creates a new thread,
gdb takes the internal breakpoint, notes the creation of the thread,
prints a message, and then continues the program.

The problem is that if one of the existing threads is inside a system
call such as sleep() or select() or read(), that sequence of events
can cause the system call to return prematurely.  This is legal
behavior, but it means that your program can behave differently
with gdb than it does without gdb.

So check your code in the threads that are affected.  Make sure that
you are checking the return value of all library calls and system calls.
Your program should be doing that anyways.

> I'm also not able to break in certain functions which are not accessed
> by the main thread.

That should work.  Can you use the 'script' command and give us a
sample session?

Hope this helps,

Michael C
GDB QA Guy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]