This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
GDB and Threading Question....
- From: Adam Oldham <adam dot oldham at gilbarco dot com>
- To: gdb at sources dot redhat dot com
- Cc: adam dot oldham at gilbarco dot com, brian dot dowtin at gilbarco dot com
- Date: 01 May 2002 08:31:57 -0400
- Subject: 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