Summary: | mmap does not handle MAP_32BIT | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Mattias EngdegÄrd <mattiase> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dschridde+kde, florian, kalvdans, mackron, philippe.waroquiers, stsp2 |
Priority: | NOR | ||
Version: | 3.8.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | (somewhat) support MAP_32BIT |
Description
Mattias EngdegÄrd
2013-08-28 19:40:33 UTC
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. |