mmap failing with EINVAL inside valgrind
in [Unix Programming]
|
From: David Schwartz on 3 Sep 2009 14:46 On Sep 3, 7:48 am, guidoreina <guidore...(a)gmail.com> wrote: > Thank you for the answers. > > The thing is that it works when I run it "normally" and it also works > when I run it with gdb, but not when I run it valgrind. This may be true, but I don't think so, and you haven't presented any evidence. Why do you think that 'mmap' shouldn't return an error? In other words, you have showed that it works differently, but not that it doesn't work. > I have just read the subject of my post... I don't want to mean that > valgrind is not working. I am having this problem and I want to > understand why this particular call to mmap is failing when I run it > with valgrind. Finding memory leaks without valgrind is too difficult, > that's why I have started this post. Can you give any reason why it shouldn't fail? Is it guaranteed to succeed by some standard? For example, is the address passed to MAP_FIXED an address it got from a previous 'mmap' call? > I want to do what Noob suggested and write a test program to see where > the problem is. The original program is using POST++ to mmap a file > and it fails in the file::open method. The base address for mmap is: > 0x62500000, and the size: 200000000. POST++ converts the size to a > multiple of 4096. Where did that address and size come from? If it didn't come from a previous 'mmap', then failure is perfectly reasonable. > So, the call is something like: > void* p = mmap(base, mapped_size, PROT_READ|PROT_WRITE, MAP_VARIABLE| > MAP_SHARED|MAP_FILE, fd, 0) > where base = 0x62500000 > and mapped_size is a bit bigger than 200000000, so it is multiple of > 4096 > > I thought that the base address could be in use when running it with > valgrind, so I checked: /proc/<pid>/maps and chose another address, > but this didn't work either. So what? Again, why does this constitute not working? Picking random addresses for mappings is not something that is ever guaranteed to work. DS
From: David Schwartz on 3 Sep 2009 16:57 On Sep 3, 12:09 pm, guidoreina <guidore...(a)gmail.com> wrote: > I don't like specifying a memory address for mmap, but the program is > like this and I cannot change it. It has to load in that memory > address. Don't ask me from where they have got that memory address > for mmap, I have never liked magic numbers. It sounds like the program works by pure luck and has just run out of luck. The original programmer probably picked a value that "worked for him" and didn't care whether it worked for you. This program is pegged to those assumptions, and now that they're not valid, neither is the program. If you can figure out what specifically is wrong with that address, you may be able to clear that address. It may help to do your debugging and testing on another machine. What OS and version is this? DS
From: Rainer Weikusat on 4 Sep 2009 07:19 David Schwartz <davids(a)webmaster.com> writes: > On Sep 3, 7:48�am, guidoreina <guidore...(a)gmail.com> wrote: >> Thank you for the answers. [...] >> I have just read the subject of my post... I don't want to mean that >> valgrind is not working. I am having this problem and I want to >> understand why this particular call to mmap is failing when I run it >> with valgrind. Finding memory leaks without valgrind is too difficult, >> that's why I have started this post. > > Can you give any reason why it shouldn't fail? Is it guaranteed to > succeed by some standard? Specifications document implementation requirements. No properties of actual implementations follow from that. > For example, is the address passed to > MAP_FIXED an address it got from a previous 'mmap' call? [...] > So what? Again, why does this constitute not working? Picking random > addresses for mappings is not something that is ever guaranteed to > work. Quoting the current UNIX(*)-standard on this (from the mmap rationale): The MAP_FIXED address treatment is likely to fail for non-page-aligned values and for certain architecture-dependent address ranges. Conforming implementations cannot count on being able to choose address values for MAP_FIXED without utilizing non-portable, implementation-defined knowledge. Nonetheless, MAP_FIXED is provided as a standard interface conforming to existing practice for utilizing such knowledge when it is available. And this basically turns the issue around: Can you quote a formal specification of any kind which specifically prohibits use of this particular value as an address on any implementation which supports MAP_FIXED? If so, is this relevant here, ie is this the implementation used by the person with the problem?
From: Scott Lurndal on 4 Sep 2009 15:22 guidoreina <guidoreina(a)gmail.com> writes: >Morning, >POST++ is "Persistent Object Storage for C++". "My" application uses >POST++ to open and use a database of objects. All the applications >which need to use the database, map it to the same address... weird. >Why don't they just let the application load the file where mmap >thinks is the right way? I don't know. Because they probably use absolute pointers in the mmap region rather than using offsets from the mmap base. Lazy programmers. scott
From: Rainer Weikusat on 4 Sep 2009 15:30
scott(a)slp53.sl.home (Scott Lurndal) writes: > guidoreina <guidoreina(a)gmail.com> writes: >>Morning, > >>POST++ is "Persistent Object Storage for C++". "My" application uses >>POST++ to open and use a database of objects. All the applications >>which need to use the database, map it to the same address... weird. >>Why don't they just let the application load the file where mmap >>thinks is the right way? I don't know. > > Because they probably use absolute pointers in the mmap region > rather than using offsets from the mmap base. Lazy programmers. Or people with different preferences. Designed in such a way, the 'object database' on disk can just be mapped into the address space of an application and immediatly yields a set of useful 'life' C++-objects. Some people always believe certain features really shouldn't exist. But insofar they do, there is obviously no consensus. Some people believe that everyone should eat only vegetables for greater purity ... |