Summary: | Running out of (internal) memory while loading shared libs | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Wolfgang Wander <wwc> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 2.2.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Wolfgang Wander
2005-01-03 18:15:17 UTC
I actually got it running my lowering KICKSTART_BASE in coregrind/Makefile.in to 7A000000 (from B0000000). Is that the preferred solution and if so, would it be worthwhile for me to consider a patch to valgrind for moving the mmaps for shared lib maps into the user space? In message <20050103194216.32034.qmail@ktown.kde.org> you wrote: > I actually got it running my lowering KICKSTART_BASE in > coregrind/Makefile.in to 7A000000 (from B0000000). Is that the preferred > solution and if so, would it be worthwhile for me to consider a patch to > valgrind for moving the mmaps for shared lib maps into the user space? What is "the user space" that you are talking about? There are serious problems at the moment with memory space - lowering the base like that helps you but hinders people with large amounts of data as it restricts the amount of space available for the program being run under valgrind. The solution is two fold - one is 64 bit machines and the other is an incremental reader for debug information. The CVS code also tried to move valgrind itself up as high as possible on systems which support position independent executables. Tom Tom Hughes wrote
>What is "the user space" that you are talking about?
>
>
Naively I was assuming I could re-call mmap from
within get_memory_from_mmap if I get a failure
but this time with VKI_MAP_CLIENT set to get
memory from the pool between between CLIENT_BASE
and client_end. But this naive assumption comes from
the fact that I don't really understand the separation of
valgrind memory and client memory in the first place...
Learning ;-)
Wolfgang
This bug sounds somewhat like a duplicate of Bug 92071. Indeed. I would also note that the reporters suggestion of retrying the map but from the client space is a bit of a bodge - it might work but defeat the object of separating valgrind's internal memory from the client's memory. For debug reading that may not be too much of an issue as it will be released again before the client gets control I think. That would need to be handled at a higher level that get_memory_from_mmap however as that is probably also used for longer term things that shouldn't be in the client space. *** This bug has been marked as a duplicate of 92071 *** |