Summary: | FV memory layout too rigid | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Nicholas Nethercote <njn> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | etphipp, jeremy |
Priority: | NOR | ||
Version: | 2.1.1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Nicholas Nethercote
2004-05-27 10:22:58 UTC
More data: A user with a 546 MB executable was having problems with no line info: > ==31711== Reading syms from <executable> > ==31711== mmap failed on <executable> They made the following change in coregrind/vg_main.c > #define VALGRIND_MAPSIZE (128*1024*1024) --- < #define VALGRIND_MAPSIZE (1024*1024*1024) And in stage2.c changed the hardcoded value for 0xb0000000. > info.map_base = 0xb0000000; --- < info.map_base = 0x78000000; This seemed to fix things, mmap now worked and the debug info appeared as expected. Change committed on 17/5/2004 improved things significantly. Valgrind + tool now have a single 256MB section for all their (non-shadow) memory needs, instead of two 128MB sections. Thus memory will be exhausted not as soon in some circumstances, eg. for Calltree. For example, previously the biggest executable that could have its debug info read would have been < 128MB, now it's < 256MB. There's still room for improvement though; I'm working on it. More data: a user with a 2GB/2GB user/kernel split was having problems because Valgrind was unable to load stage2 at 0xb0000000--0xbfffffff. Changing Valgrind to load at 0x70000000--0x7fffffff works to an extent; Addrcheck, Massif and Cachegrind work, but Memcheck and Helgrind don't because they use so much memory that 0x40000000 isn't available to the client, so standard mmap() calls fail. Also, the hard-wiring to 0xb0000000 means that systems with 4GB user-space are not utilising the top 1GB. More data: Julian had problems with Memcheck and Helgrind on a stock RH8.0 (kernel 2.4.18-14). The big shadow memory mmap() was failing at startup. Problem seemed to be that the kernel didn't support allocate-on-write mmap segments, and so it refused to mmap() a segment larger than the available swap space. Increasing the swap space to 1.9GB (Memcheck requires about 1.5GB for shadow memory) made it work. We've had a few similar complaints that could have had the same cause. So, that's a black mark against the use of really big mapped segments; an incremental approach may well be better. The problem from comment #3 has been partly fixed: we are now building Valgrind as a position-independent executable (PIE) on systems that support it (ie. ones with more recent versions of gcc and ld). This means that systems that don't have the standard 3G:1G user/kernel split work better. More data: a number of users have had problems with symbols not being read from big files. It seems 300MB+ executables are not that uncommon; one user had a 900MB executable. Incremental loading of symbols would seem to be the right way to handle this. *** Bug 101271 has been marked as a duplicate of this bug. *** Julian's aspacem rewrite has fixed this. Eg. see the resolution for bug #92071 which was about the large debug info problem. Good work Julian! |