|
From: Alexander P. <gl...@go...> - 2013-06-04 14:55:17
Attachments:
aspacem.patch
|
Hi all, I've been debugging an error in Valgrind due to which the symbol table for a large 32-bit binary (content_unittests from the Chromium project, see https://code.google.com/p/chromium/issues/detail?id=245745 for more details) wasn't loaded on OS X 10.6. The following error was printed for --trace-symbols=yes: --1448-- WARNING: Serious error when reading debug info --1448-- When reading debug info from src/xcodebuild/Release/content_unittests: --1448-- Can't mmap image to read symbols?! I've added some printfs and address space dumping and figured out that for a mapping of 259089676 bytes (247.1M) VG_(am_get_advisory) was returning the range "00f077c000-00fffebfff" of 248M, which it thought was free. However a further call to mmap(00f077c000, 259089676, ...) failed with ENOMEM. I suppose that the problem here is that the address space manager is unaware about some portions of the address space that are reserved by the kernel. For example, according to Amit Singh's "Mac OS X Internals", page 910 (http://goo.gl/AeD2o), the memory above 0xfe000000 is reserved for various system services. I've replaced the current value of aspacem_maxAddr (0xffffffff) with 0xfdffffffff, effectively disallowing the address space manager to use the reserved memory. This worked in my case, and I think the patch (attached) needs to be upstreamed. However I couldn't find any actual documentation on the address space layout of the recent OSX versions (Singh's book refers to 10.4), so I'm not sure if this is portable. Is anyone aware of any information about the reserved page ranges in the recent OSX kernels? Is my approach to fix the problem correct at all? I'm also curious about other potential consequences of this issue. Looks like arbitrary mmap() calls in Valgrind may unexpectedly fail on 32-bit Darwin if they overlap with the reserved ranges. Thanks, Alexander Potapenko Software Engineer Google Moscow |
|
From: Philippe W. <phi...@sk...> - 2013-06-04 18:08:32
|
On Tue, 2013-06-04 at 18:55 +0400, Alexander Potapenko wrote: > I'm also curious about other potential consequences of this issue. > Looks like arbitrary mmap() calls in Valgrind may unexpectedly fail on > 32-bit Darwin if they overlap with the reserved ranges. It looks like there is already a bunch of tricks which are bypassing or ignoring differences between Valgrind aspacemgr view of the mappings and the real kernel mappings. Search for several VGO_darwin conditional compilations in aspacemgr-linux.c. Your specific problem might be a special case of a maybe more general problem which is handled in VG_(am_mmap_anon_float_valgrind) but not in VG_(am_mmap_file_float_valgrind_flags). It might maybe be better to have a single place that calls "advise" then "mmap", and that would do recovery on Darwin by retrying without MAP_FIXED when failing (this would also be useful for an "outer valgrind" running an "inner valgrind", as the inner valgrind encounters similar differences as it cannot observe the mmap syscalls done by the outer valgrind). Philippe |
|
From: Julian S. <js...@ac...> - 2013-06-10 11:59:12
|
Although it doesn't address the underlying aspacem problems, a possible workaround to Alexander's problem is to use the DISRV branch, which (amongst things) changes the debuginfo reader so it doesn't have to map in the entire file. Instead only a fixed amount of memory (1MB approximately) is required, regardless of the file size. See recent message on this list "Remote debuginfo server". This doesn't yet work for MacOS, since I haven't changed the Mach-O reader to use the new internal interface (priv_image.h), but that's in progress. J On 06/04/2013 08:08 PM, Philippe Waroquiers wrote: > On Tue, 2013-06-04 at 18:55 +0400, Alexander Potapenko wrote: >> I'm also curious about other potential consequences of this issue. >> Looks like arbitrary mmap() calls in Valgrind may unexpectedly fail on >> 32-bit Darwin if they overlap with the reserved ranges. > It looks like there is already a bunch of tricks which are bypassing > or ignoring differences between Valgrind aspacemgr view of the mappings > and the real kernel mappings. > Search for several VGO_darwin conditional compilations in aspacemgr-linux.c. > > Your specific problem might be a special case of a > maybe more general problem which is handled in VG_(am_mmap_anon_float_valgrind) > but not in VG_(am_mmap_file_float_valgrind_flags). > > It might maybe be better to have a single place that calls > "advise" then "mmap", and that would do recovery on Darwin > by retrying without MAP_FIXED when failing > (this would also be useful for an "outer valgrind" running > an "inner valgrind", as the inner valgrind encounters > similar differences as it cannot observe the mmap syscalls > done by the outer valgrind). > > Philippe > > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |