| 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 First Reported In: | 3.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
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. |
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