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]

GDB and Threading Question....


Hello,

I posted a few months ago about having problems debugging a
multi-threaded app with GDB when the threads are running with SCHED_RR
(real time) policy in linux.  We tried to run GDB by starting GDB with
the excutable name of the program to debug (all from the command line),
and starting the executable within GDB.  This seemed to cause either the
threads to run at non-realtime policies or interfered with threads
enough that they were not even close to running at the right priorities.
The answer then was simple, "Thread debugging is intrusive."

I just downloaded the new release of GDB to give it a shot again.  The
same technique as above happens in the same manner as it did in 5.0.
However, I can start the application and attach to the root application
PID with GDB.  This seems to actually work.  It recognizes all the PIDs
that get created and allows coders to debug in multiple threads and
doesn't _seem_ to interfere with scheduling.

However, with this technique comes questions that I am hoping someone
answers.  Debugging in the method like this (attaching to an already
running PID), will GDB hinder or change the scheduling policy of any new
threads that are created? (meaning to cause new threads started with
policy SCHED_RR or SCHED_FIFO to be started as SCHED_OTHER).  Or will
GDB interfere will priorities that PIDs are supposed to run at?

Thanks!
Adam Oldham



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