The mmap MAP_32BIT flag, specific to x86-64 on Linux, seems to be ignored. Correct behaviour is to return a block entirely within the lowest 2 GiB or MAP_FAILED (ENOMEM) if such a request could not be satisfied. This is a problem because some software rely on MAP_32BIT to work properly, and misbehave if a block beyond 2**31 is returned (which never happens when running outside Valgrind). Strictly speaking, it would even in some sense be correct to always fail mmap with MAP_32BIT; at least that would not violate the specification as openly. However, without knowing details about how things are implemented, supporting the flag should be easy work (just fail and munmap if we got a mapping in the wrong place). Reproducible: Always Steps to Reproduce: 1. mmap(NULL, somesize, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_32BIT, -1, 0) 2. repeat point 1 until it returns something beyond 0x80000000 Actual Results: mmap(MAP_32BIT) eventually returns a block beyond 2**31. Expected Results: mmap(MAP_32BIT) should never return a block beyond 2**31 but MAP_FAILED instead.
Yes, we shouldn't silently ignore this flag. r13644 makes any such call always fail. Seems like the simplest solution considering that this flag is totally unportable.
Having mmap() always fail breaks LuaJIT, which is fairly widely used. Is it not possible to only return an ENOMEM error if the mapping goes beyond the allowed range? I reckon it would work successfully for the most part (LuaJIT works fine in practice with previous versions of Valgrind) - I feel like that's better than it never working.
MAP_32BIT is used by dosemu for creating a 32bit segments. It is likely also used in wine for the same reason. While this flag is non-portable, it has its valid use: for legacy system emulators, which are non-portable themselves. There is simply no way such emulators can work without this flag. No work-around (other than to emulate this flag by looking into /proc/self/maps). Is this flag really that difficult to implement?
Created attachment 93202 [details] (somewhat) support MAP_32BIT Can you try the attached patch ? (based on revision Revision: 15339) Thanks The patch should allow to properly support MAP_32BIT, at least as long as there is some free space in the first 2GB. Note that Valgrind aspacemgr does no effort to keep the first 2GB free (to the contrary: it starts mmap-ing in this area, with or without MAP_32BITS). So, the first 2GB might be exhausted a lot more quickly under VAlgridn than with a native run for which it seems the kernel tries to keep the lower address space free.
Great patch, thanks! Note that the solution you propose, is perfectly fine for the real life: the emulators I mentioned, can work on 32bit systems too (obviously), so they will never exhaust the 2GB of address space. I made sure dosemu goes much further with your patch, which is a big step forward. Unfortunately, its not enough. To get either wine or dosemu to work with valgrind, someone have to re-visit this ticket: https://bugs.kde.org/show_bug.cgi?id=253657
Fixed in Revision: 15341 Thanks for the testing.
(In reply to Stas Sergeev from comment #5) > To get either wine or dosemu to work with valgrind, > someone have to re-visit this ticket: > https://bugs.kde.org/show_bug.cgi?id=253657 See comments I will add in 253657
(In reply to Philippe Waroquiers from comment #7) > See comments I will add in 253657 Subscribed now. :)
(In reply to Philippe Waroquiers from comment #6) > Fixed in Revision: 15341 Has this been released already?
(In reply to Dennis Schridde from comment #9) > (In reply to Philippe Waroquiers from comment #6) > > Fixed in Revision: 15341 > > Has this been released already? Yes. This is in Valgrind 3.11.0, released the 22 September 2015 Note: the NEWS file indicates the svn revision used for the TEST and final releases.