This is the mail archive of the gdb@sourceware.org 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: Multiple inferiors and memory consumption


On Tue, 2012-07-10 at 00:31 +0400, Vladimir Prus wrote:
> It could be me, but I always expected that using GDB multi-process functionality should be better than
> separate GDB instances -- including memory consumption. So, I've just tried to run CVS gdb on itself
> inside 4 inferiors, and it looks like each inferior, the amount of data used by GDB (the DATA column
> in top) grows pretty much linearly. That is, it does not seem like GDB notices that symbol tables of
> all 4 loaded executables are identical (There's a link to the chart: http://goo.gl/0auVf)

We ran across the same problem some time back. There is a comment in
objfiles.h:

FIXME:  There is a problem here if the objfile is reusable, and if
        multiple users are to be supported.  The problem is that the 

so it looks like at least one person has thought about re-using objfile
in the past.

We have a patch that allows multiple programs_spaces to share the same
objfiles by moving the linked list entry into a new struct
objfile_instance.

> And now for my real question -- is there any case when using
> multi-process to debug several applications
> not related via parent-child relationship is better than running N
> copies of GDB?

Most of the time, no. If you are debugging so many processes that the
per GDB memory overhead is starting to hurt then yes, but only if you
are sharing symbol files between inferiors as above.

Regards,
Chris January



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