This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multiple inferiors and memory consumption
- From: Chris January <chris dot january at allinea dot com>
- To: gdb at sourceware dot org
- Date: Tue, 10 Jul 2012 09:03:54 +0100
- Subject: Re: Multiple inferiors and memory consumption
- References: <4FFB3F86.2000109@codesourcery.com>
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