Re: [Valgrind-users] valgrind/memcheck and programs using mmap()

[John R. <jr...@Bi...>]

Dan...@ba... wrote:
> The program I am debugging does a large mmap()
> 
> Some small mmap() calls seem to work, but the large mmap(), for an 80GB
> file, results in EINVAL
> 
> I've verified that the offset is 0 and the mapping size is a multiple of
> getpagesize().  The mmap() does work when not using valgrind.
> 
> Is there some kind of mmap() restriction or size limit with valgrind?  I
> searched for mmap in the documentation and didn't find anything.

The restriction is that there is only one address space that must hold
both the application data and the valgrind(memcheck) data.

When the mmap() fails with EINVAL, then look at the address space using
     cat /proc/<pid>/maps
and see if there is 80MB contiguous space available.  What other things
are notable about the memory usage as shown by /proc/<pid>/maps ?
(Many threads, many "holes", many large blocks, many shared libs, ...?)

If you are running on i686 with the common allocation of 3GB of address
space for user mode and 1GB for the Linux kernel, then try running the
same program (same binary object file) on x86_64 under a 64-bit kernel
that supports the execution of 32-bit user-mode programs.  Most common
Linux distributions provide such support.  In this mode you often get
almost 4GB of address space that is accessible by a 32-bit user program,
which may be enough more for your purpose.

If the application is portable to a native 64-bit environment, then
compile and run the app in that environment.  There is more address
space, and the application's memory leak is likely to persist.

--