Summary: | mmap failed in UME with error 22 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Chris Gibson <chris.m.gibson> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 3.2.1 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Chris Gibson
2006-12-15 21:03:18 UTC
I don't know how this even works without Valgrind. AFAICT, you're statically allocating 9 * 10000 * 10000 * 8 bytes, which is 6.7GB, on a 32-bit machine. But it runs on my x86 box so my calculations must be off somehow. And Valgrind is trying to allocate 2.8GB. Anyway, on x86/Linux Valgrind loads itself at 0x38000000. To change this, change this line in 'configure': valt_load_address_normal="0x38000000" to a value like 0xb7000000, then re-configure and re-build. You may have to play around a bit to find a value that works. Assuming the program needs about 3GB, even in the best case on an x86 platform (running a 4G + 4G kernel and messing with V's load address) the chances of a successful outcome are small. Probably quicker and easier to build it as a 64-bit application and use a 64-bit build of Valgrind. True, but on amd64 Valgrind's load address is also 0x38000000, so you may still have to change it. I don't think we have much chance of getting your program to work on a 32-bit platform. But we should produce an error message which is at least somewhat meaningful to users; "mmap failed in UME with error 22" is pretty hopeless. *** This bug has been marked as a duplicate of 138424 *** Can't easily fix this, but I did commit a change to make it print a more intelligible error message. |