2fabdf3381
This patch started as an observation from valgrind that GDB appeared
to be loosing track of some memory associated with types. An example
valgrind stack would be:
24 bytes in 1 blocks are possibly lost in loss record 419 of 5,361
at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
by 0x623D26: xcalloc (common-utils.c:85)
by 0x623D65: xzalloc(unsigned long) (common-utils.c:95)
by 0x72A066: make_function_type(type*, type**) (gdbtypes.c:510)
by 0x72A098: lookup_function_type(type*) (gdbtypes.c:521)
by 0x73635D: gdbtypes_post_init(gdbarch*) (gdbtypes.c:5439)
by 0x727590: gdbarch_data(gdbarch*, gdbarch_data*) (gdbarch.c:5230)
by 0x735B99: builtin_type(gdbarch*) (gdbtypes.c:5313)
by 0x514D95: elf_rel_plt_read(minimal_symbol_reader&, objfile*, bfd_symbol**) (elfread.c:542)
by 0x51662F: elf_read_minimal_symbols(objfile*, int, elfinfo const*) (elfread.c:1121)
by 0x5168A5: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1207)
by 0x8520F5: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:794)
When we look in make_function_type we find a call to TYPE_ZALLOC
(inside the INIT_FUNC_SPECIFIC macro). It is this call to TYPE_ZALLOC
that is allocating memory with xcalloc, that is then getting lost.
The problem is tht calling TYPE_ALLOC or TYPE_ZALLOC currently
allocates memory from either the objfile obstack or by using malloc.
The problem with this is that types are allocated either on the
objfile obstack, or on the gdbarch obstack.
As a result, if we discard a type associated with an objfile then
auxiliary data allocated with TYPE_(Z)ALLOC will be correctly
discarded. But, if we were ever to discard a gdbarch then any
auxiliary type data would be leaked. Right now there are very few
places in GDB where a gdbarch is ever discarded, but it shouldn't hurt
to close down these bugs as we spot them.
This commit ensures that auxiliary type data is allocated from the
same obstack as the type itself, which should reduce leaked memory.
The one problem case that I found with this change was in eval.c,
where in one place we allocate a local type structure, and then used
TYPE_ZALLOC to allocate some space for the type. This local type is
neither object file owned, nor gdbarch owned, and so the updated
TYPE_ALLOC code is unable to find an objstack to allocate space on.
My proposed solution for this issue is that the space should be
allocated with a direct call to xzalloc. We could extend TYPE_ALLOC
to check for type->gdbarch being null, and then fall back to a direct
call to xzalloc, however, I think that making this rare case of a
local type require special handling is not a bad thing, this serves to
highlight that clearing up the memory will require special handling
too.
This special case of a local type is interesting as the types owner
field (contained within the main_type) is completely null. While
reflecting on this I looked at how types use the get_type_arch
function. It seems clear that, based on how this is used, it is never
intended that null will be returned from this function. This only
goes to reinforce, how locally alloctaed types, with no owner, are
both special, and need to be handled carefully. To help spot errors
earlier, I added an assert into get_type_arch that the returned arch
is not null.
Inside gdbarch.c I found a few other places where auxiliary type data
was being allocated directly on the heap rather than on the types
obstack. I have fixed these to call TYPE_ALLOC now.
Finally, it is worth noting that as we don't clean up our gdbarch
objects yet, then this will not make much of an impact on the amount
of memory reported as lost at program termination time. Memory
allocated for auxiliary type information is still not freed, however,
it is now on the correct obstack. If we do ever start freeing our
gdbarch structures then the associated type data will be cleaned up
correctly.
Tested on X86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* eval.c (fake_method::fake_method): Call xzalloc directly for a
type that is neither object file owned, nor gdbarch owned.
* gdbtypes.c (get_type_gdbarch): Add an assert that returned
gdbarch is non-NULL.
(alloc_type_instance): Allocate non-objfile owned types on the
gdbarch obstack.
(copy_type_recursive): Allocate TYPE_FIELDS and TYPE_RANGE_DATA
using TYPE_ALLOC to ensure memory is allocated on the correct
obstack.
* gdbtypes.h (TYPE_ALLOC): Allocate space on either the objfile
obstack, or the gdbarch obstack.
(TYPE_ZALLOC): Rewrite using TYPE_ALLOC.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.