|
From: kirk j. <tu...@in...> - 2004-06-08 16:06:15
|
KJ = kirk johnson
NN = nicholas nethercote
KJ > 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.
NN > I think it's a Valgrind core issue, that perhaps only Massif
> exposes.
entirely possible.
NN > It may be a manifestation of bug #82301
> (bugs.kde.org/show_bug.cgi?id=82301).
yeah, i'm seeing a different failure mode, but i think the basic
problem is the same -- i'm running out of mmap space.
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.
another option would be to try some version of the patch that's listed
at the end of bug #82301.
NN > Hmm, I hadn't considered that some XPts could become non-live.
> My gut feeling is that the number wouldn't be that significant,
> but I would be happy to be proved wrong.
mostly a guess on my part, no data to support it -- i was simply
trying to come up with an explanation for why we were going through
128 MB worth of XPt objects ...
NN > The number of XPts is bound by the size of the program, rather
> than the running time. It's also possible that an XPt could
> become dead and then alive again later, in which case it would
> be reallocated.
exactly the sort of thing i was wondering about.
NN > I think option 2 would be the better one.
good for a short term fix, but if a significant number of XPt objects
are going non-live and/or then being reallocated, then it may not be
the right long-term fix ...
tx for the pointers, i'll see if i can get something working today and
let you know what happens.
kirk
|