|
From: kirk j. <tu...@in...> - 2004-06-10 07:48:19
|
NN = nicholas nethercote
KJ = kirk johnson
NN > As a temporary workaround, you could try installing Valgrind
> 2.0.0, which lays out memory differently, and then plumbing in
> Massif (it wasn't added until 2.1.0), which will require some
> judicious copying and editing of configure.in and Makefile.am.
KJ > another option would be to try some version of the patch that's
> listed at the end of bug #82301.
i tried the approach listed at the end of bug #82301 -- i tweaked
VALGRIND_MAPSIZE to 256 MB and info.map_base to 0xa8000000 -- but it
didn't change the failure mode. in fact, even if i upped
VALGRIND_MAPSIZE to 512 MB (and made the corresponding change to
info.map_base), that still doesn't help. even worse, things still fail
at essentially the same point in the program execution.
digging a little deeper, it ends up being rather obvious why this is
-- the VG_(get_memory_from_mmap) code is allocating from between
VG_(valgrind_mmap_end) and VG_(valgrind_end), and the values of these
variables are not affected by the dinking around with VALGRIND_MAPSIZE
and info.map_base. said dinking _does_ cause the value of
VG_(valgrind_base) to change, but since that doesn't affect the range
of memory available for VG_(get_memory_from_mmap) to allocate from, it
doesn't address the problem at hand.
brief thought was given to the idea of replacing the calls to
perm_malloc with calls to VG_(malloc), but that wouldn't help either
-- in the end, memory allocated by VG_(malloc) is also coming out of
the pool managed by VG_(get_memory_from_mmap).
looking more closely at coregrind/vg_main.c, i see that
VG_(valgrind_mmap_end) and VG_(valgrind_end) are set up in
layout_client_space(). alas, the values assigned to these variables
appear to be out of my control -- VG_(valgrind_mmap_end) is coming
from the location of kickstart_end (apparently a "magic" symbol
defined by the linker/loader?), while VG_(valgrind_end) is coming from
the location at which main() is passed its arguments. thus, we're left
with a handful of possible solutions:
1) find a way to change the locations of kickstart_end and/or the
arguments that are passed to main(), thus increasing the amount of
space availble to VG_(get_memory_from_mmap). although this doesn't
_solve_ the problem, perhaps it puts it off far enough to work
around my immediate difficulties.
2) revise the memory allocation scheme such that once
VG_(get_memory_from_mmap) runs out of space between
VG_(valgrind_mmap_end) and VG_(valgrind_end), additional memory
segments can be allocated from elsewhere (either the same pool
that the client heap is being drawn from or from unused parts of
the VG_(valgrind_base) to VG_(valgrind_mmap_end) range). this
would seem to run at least partly counter to the
full-virtualization efforts (and may in fact be closer to how
things were done in valgrind-2.0.0; i haven't looked at the code
to see).
3) get lucky and discover that non-trivial numbers of XPt objects are
going non-live (and possibly being reallocated later); provide a
means of reclaiming these XPt objects and any associated memory
(e.g., free the child data, freelist the XPt objects). obviously
this only helps if non-trivial numbers of XPt objects are going
non-live, an assumption that i have not investigated further.
thoughts?
tx for the help,
kirk
|