[Valgrind-users] massif/valgrind-2.1.1 problems

[tunaNO@SPAMindra.com]

i'm trying to use massif to analyze the behavior of some rather large
applications. for many "interesting" problem sizes, massif/valgrind
(this is in the context of valgrind 2.1.1) blows out with:

 valgrind: vg_mylibc.c:1681 (vgPlain_get_memory_from_mmap): Assertion
 `p >= (void *)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end'
 failed.

vg_mylibc.c:1681 corresponds to a bounds-checking assertion in
"VG_(get_memory_from_mmap)"; i've instrumented that code and verified
that the problem appears to be an _overflow_ of those bounds.

because i don't see the same problems running the same applications
and problem sizes under calltree/valgrind, i'm assuming this is a
massif-specific issue. digging around, i see a call to
"VG_(get_memory_from_mmap)" at ms_main.c:372 coming out of
"perm_malloc", which is prefaced with the following comment:

 // Cheap allocation for blocks that never need to be freed. Saves
 // about 10% for Konqueror startup with --depth=40.

"perm_malloc" looks to be called from "new_XPt", which appears to be
the code that is used to allocate new execution/allocation points in
the instrumentation scheme used by massif. so one assumes that the
assertion at vg_mylibc.c:1681 is ultimately failing because we've run
out of space to allocate more XPt objects, and perhaps that there is
something interesting about these applications (long runtimes? large
number of allocation points?) that is causing enough XPt objects to be
allocated for me to run afoul of such problems.

it is unclear to me at this point whether or not the periodic calls to
"halve_censi" may in fact be removing some XPt objects from further
consideration without providing a means for ever reusing them, thus
exacerbating the problems suggested above.

without digging into ms_main.c too much further (yet!), it appears to
me that there might be a handful of different ways of attacking this
problem:

 1) assuming "halve_censi" (or some other mechanism?) does indeed
    remove some XPt objects from further consideration without
    providing a means for ever reusing them, provide such a
    means:

    a) simplest solution here is probably a freelist that
       no-longer-used XPt objects are pushed onto, and new XPt objects
       are popped from when possible.

    b) alternate approach would be to eliminate the calls to
       "perm_malloc" in favor of calls to a conventional "malloc",
       taking care to insert corresponding calls to "free" for XPt
       objects that will no longer be used.

 2) provide a means of expanding the size of the memory segment that
    is available for "VG_(get_memory_from_mmap)" to work with.

of these, 1a would seem to be the most straightforward and promising
approach, but that's only if the assumption about XPt object use holds
true, which i'm completely unclear on.

thoughts/comments/suggestions?

tx,

kirk

ps. i'm not subscribed to val...@li..., so
please include my e-mail address (modulo obvious anti-spam -- remove
the NO and SPAM) in your response. just in case, i'll also try to keep
an eye on the valgrind-users archives ...