|
From: Nicholas N. <nj...@cs...> - 2008-11-04 23:12:16
|
On Tue, 4 Nov 2008, John Reiser 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. He said 80GB, not 80MB, so I assume it's already on x86-64. That's a pretty big file -- not much in a 64-bit address space, admittedly -- but it may be big enough to cause Valgrind problems, not sure. Nick |