Re: gdb and cloned process

[Michael Snyder <msnyder at vmware dot com>]

Lukasz Lempart wrote:
> On Thu, Oct 23, 2008 at 11:26 AM, Michael Snyder <msnyder@vmware.com> wrote:
> > Daniel Jacobowitz wrote:
> > > On Wed, Oct 22, 2008 at 05:09:32PM -0700, Lukasz Lempart wrote:
> > > > How does gdb (through libthread_db) figure out what threads belong to a
> > > > process?
> > > The thread library maintains an internal list of threads.  If you've
> > > cloned the process, without telling the C library about that, you're
> > > going to end up with the same list of threads; so the behavior you
> > > describe is not surprising.
> > >
> > > > Is there currently a way to disable thread debugging in gdb?
> > > Not really.  You might be able to preload a dummy libthread_db.so.1
> > > that always failed to detect new threads.
> > What if you strip libthread.so?  Isn't that supposed to
> > cause thread debugging to fail?
>
> Stripping libthread_db.so seems to do the trick. Thanks for the
> suggestion. Keeping both version of the library around and just
> changing LD_LIBRARY_PATH to point to the one I want seems to be the
> most portable way to handle debugging both the original and the cloned
> process. A gdb command to turn on/off thread debugging would be very
> nice to have though.

Cool... so tell us a little bit about your application, please.

What sorts of data are you monitoring in the running process,
how are you monitoring the data, how often are you updating it,
and how useful has the technique proven to be?

And have you thought ahead as far as actually modifying
the data of the running process?