This is the mail archive of the gdb-patches@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]

Re: [PATCH RFA] process/thread/lwp identifier mega-patch


On Feb 16,  9:24am, Andrew Cagney wrote:

> One thought on this (prompted by a side conversation).  From memory you
> had concerns with your memory [groan] (i.e. memory leaks).
> 
> Have you considered ignoring the problem?  Well actually just
> accumulating a list of all the created threads and then, when GDB
> re-starts a target, deleting the lot?  Yes, this will clearly not scale
> well in an application that creates then deletes millions of threads. 
> Hopefully though, the benefits (such as improved performance) of having
> per thread objects will far out way this.
> 
> I suspect that the way GDB currently tries to delete threads is
> technically flawed - it only worked because there was really only one
> thread.  A better more robust model needs to be developed but I don't
> think solving that problem should be part of this patch.  The person
> with the million threads can solve that one :-)

I think that your suggestion could be made to work, though it won't
be as simple as merely wiping out the thread list when GDB restarts
a target.  The reason?  Dangling pointers in static globals.

E.g, in infrun.c, we have the following declaration:

	static int static int previous_inferior_pid;

My patches change this declaration to:

	static struct ptid *previous_inferior_ptid;

We would need to make sure this (and other static globals) are
reinitialized when the thread list is wiped out.

Another alternative is to make the execution context identifiers (or
ECIs for short) ``struct ptid'' instead of ``struct ptid *''.  I.e,
make the ECI a struct instead of a pointer to a struct.  The problem
with doing this is that the ECI's type can no longer be opaque.

One can argue that if GDB accesses a defunct ECI (regardless of
implementation) at all, it is behaving incorrectly, because this
behavior is wrong regardless of whether the ECI is a struct or a
dangling pointer.  It's just that it could be catastrophic if it's the
latter...

So maybe it'd be best if we make sure that each and every ECI
occurence in the code is initialized properly when the thread list is
cleaned up.  (In other words, I'm coming around to liking your
suggestion again...)

Kevin


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