|
From: Nicholas N. <nj...@ca...> - 2004-06-08 07:40:33
|
On Mon, 7 Jun 2004 tunaNO@SPAMindra.com wrote: > 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. I think it's a Valgrind core issue, that perhaps only Massif exposes. It may be a manifestation of bug #82301 (bugs.kde.org/show_bug.cgi?id=82301). Josef, is this the same error you are getting with Calltree on big programs? 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. > 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. 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. 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. I think option 2 would be the better one. N |