While trying to run Valgrind on a rather complex and large application, I received the following error on startup. valgrind: mmap(0x80A5000, 3050393600) failed in UME with error 22. Because the system under test is classified, I wrote a simple program that yields the same results: //Start double big_array_tester[10000][10000]; double big_array_tester2[10000][10000]; double big_array_tester3[10000][10000]; double big_array_tester4[10000][10000]; double big_array_tester5[10000][10000]; double big_array_tester6[10000][10000]; double big_array_tester7[10000][10000]; double big_array_tester8[10000][10000]; double big_array_tester9[10000][10000]; int main() { } //End I know these arrays are huge, but the application I'm trying to debug has similar arrays heavily ingrained in it. I.e., they can not be removed or reworked. I traced where this error is being thrown in the valgrind code and found that it stems from the file aspacemgr.c, method Addr VG_(am_get_advisory). The following block of code in this method hits a space in memory that is allocated to valgrind: if (forClient && req->rkind == MFixed) { Int iLo = find_nsegment_idx(reqStart); Int iHi = find_nsegment_idx(reqEnd); Bool allow = True; for (i = iLo; i <= iHi; i++) { if (nsegments[i].kind == SkFree || nsegments[i].kind == SkFileC || nsegments[i].kind == SkAnonC || nsegments[i].kind == SkShmC || nsegments[i].kind == SkResvn) { /* ok */ } else { allow = False; break; } } if (allow) { /* Acceptable. Granted. */ *ok = True; return reqStart; } /* Not acceptable. Fail. */ *ok = False; return 0; } The allow variable is set to False when nsgments[5].kind = 4, where 4 = SkFileV (file mapping belonging to valgrind). I traced no further than this. I'm running on an IHawk Linux PC with 4G or RAM, and a 100G hard drive. uname -a yields: Linux 2.6.9 -RedHawk-2.3-snare #2 SMP GMT-5 2005 i686 i386 GNU/Linux Any help fixing this problem would be greatly appreciated. -Chris Gibson
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.