I have a program (on 64-bit linux) which does mmap(0, 84G, ...). When running natively, it works perfectly. Under valgrind it fails. % cat mmap_test.c #include <stdint.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/mman.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <stdio.h> int main() { size_t size = (1ULL << 32) * 21; // 21 * 4G void *mem_ptr = mmap((void *) 0, size, PROT_EXEC | PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_NORESERVE, -1, (off_t) 0); printf("res=%p\n", mem_ptr); return 0; } % gcc mmap_test.c -m64 && ./a.out && ~/valgrind/trunk/inst/bin/valgrind --tool=none -q ./a.out res=0x7f4fd9019000 res=0xffffffffffffffff P.S. Allocating 84G of memory is not insane. We need a chunk of memory with huge guard pages around it. If curious, this code is a part of Native Client.
This patch seems to help. Why is the constant 32G? Can it be changed in trunk? --- coregrind/m_aspacemgr/aspacemgr-linux.c (revision 11088) +++ coregrind/m_aspacemgr/aspacemgr-linux.c (working copy) @@ -1642,7 +1642,7 @@ aspacem_minAddr = (Addr) 0x04000000; // 64M # if VG_WORDSIZE == 8 - aspacem_maxAddr = (Addr)0x800000000 - 1; // 32G + aspacem_maxAddr = (Addr)0x8000000000 - 1; // 512G # ifdef ENABLE_INNER { Addr cse = VG_PGROUNDDN( sp_at_startup ) - 1; if (aspacem_maxAddr > cse)
(In reply to comment #1) > This patch seems to help. This patch will make it work, but what you will find is that Memcheck processes memory accesses in the new range (32G-512G) very much more slowly than in the existing range (0-32G), and you will almost certainly see a big slowdown. The reasons for this are explained in detail in a big comment starting at memcheck/mc_main.c:111, so I won't repeat them here. Really you need to change both aspacem_maxAddr in aspacemgr-linux.c and N_PRIMARY_BITS in mc_main.c together. I think the relationship is that aspacem_maxAddr == (1 << (N_PRIMARY_BITS+16)) - 1, although you should check that. If you read the comment in mc_main.c, it should be clear why the 32G limit exists -- to raise it to eg 512G and hot have any performance loss would require having a huge primary map (many tens of megabytes).
s/hot have any performance loss/not have any performance loss/g
in fact, 256G is quite enough to run Valgrind on NaCl. So, the patch would be this (plus changes in comments): =================================================================== --- coregrind/m_aspacemgr/aspacemgr-linux.c (revision 11094) +++ coregrind/m_aspacemgr/aspacemgr-linux.c (working copy) @@ -1642,7 +1642,7 @@ aspacem_minAddr = (Addr) 0x04000000; // 64M # if VG_WORDSIZE == 8 - aspacem_maxAddr = (Addr)0x800000000 - 1; // 32G + aspacem_maxAddr = (Addr)0x4000000000 - 1; // 256G # ifdef ENABLE_INNER { Addr cse = VG_PGROUNDDN( sp_at_startup ) - 1; if (aspacem_maxAddr > cse) Index: memcheck/mc_main.c =================================================================== --- memcheck/mc_main.c (revision 11094) +++ memcheck/mc_main.c (working copy) @@ -168,7 +168,7 @@ /* Just handle the first 32G fast and the rest via auxiliary primaries. If you change this, Memcheck will assert at startup. See the definition of UNALIGNED_OR_HIGH for extensive comments. */ -# define N_PRIMARY_BITS 19 +# define N_PRIMARY_BITS 22 #endif @@ -5961,11 +5961,11 @@ tl_assert(sizeof(Addr) == 8); tl_assert(sizeof(UWord) == 8); tl_assert(sizeof(Word) == 8); - tl_assert(MAX_PRIMARY_ADDRESS == 0x7FFFFFFFFULL); - tl_assert(MASK(1) == 0xFFFFFFF800000000ULL); - tl_assert(MASK(2) == 0xFFFFFFF800000001ULL); - tl_assert(MASK(4) == 0xFFFFFFF800000003ULL); - tl_assert(MASK(8) == 0xFFFFFFF800000007ULL); + tl_assert(MAX_PRIMARY_ADDRESS == 0x3FFFFFFFFFULL); + tl_assert(MASK(1) == 0xFFFFFFC000000000ULL); + tl_assert(MASK(2) == 0xFFFFFFC000000001ULL); + tl_assert(MASK(4) == 0xFFFFFFC000000003ULL); + tl_assert(MASK(8) == 0xFFFFFFC000000007ULL); # endif } This will increase the primary map by 8x. Is this a big problem on 64-bit systems? Is there a chance to see this change in trunk?
I see memcheck has an --ignore-range commandline option to bypass checks on an address range. Would it be possible to define a client request to ignore mmap(...,size) ? Meaning that the immediately subsequent mmap request would be passed thru to the kernel, and the resulting memory would be ignored by valgrind, so it doesn't need to fit in valgrind's address space management. I was just about to open a wishlist ticket for this feature, but stumbled across this bug report along the way.