Running wine 1.7.26 from macports fails to load the binary into memory: $ valgrind -d --tool=cachegrind --trace-children=yes wine bin.exe --72132:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --72132:1:launcher tool 'cachegrind' requested --72132:1:launcher valgrind_lib = /usr/local/lib/valgrind --72132:1:launcher arch 'x86' IS installed --72132:1:launcher arch 'amd64' IS installed --72132:1:launcher arch 'arm' IS NOT installed --72132:1:launcher arch 'ppc32' IS NOT installed --72132:1:launcher arch 'ppc64be' IS NOT installed --72132:1:launcher selected arch 'x86' --72132:1:launcher launcher_name = /usr/local/bin/valgrind --72132:1:launcher launching /usr/local/lib/valgrind/cachegrind-x86-darwin --72132:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --72132:1:main Welcome to Valgrind version 3.10.0 debug logging --72132:1:main Checking current stack is plausible --72132:1:main Checking initial stack was noted --72132:1:main Starting the address space manager --72132:1:main Address space manager is running --72132:1:main Starting the dynamic memory manager --72132:1:mallocfr newSuperblock at 0xF0001000 (pszB 4194288) owner VALGRIND/core --72132:1:mallocfr deferred_reclaimSuperblock at 0xF0001000 (pszB 4194288) (prev 0x0) owner VALGRIND/core --72132:1:main Dynamic memory manager is running --72132:1:main Initialise m_debuginfo --72132:1:main VG_(libdir) = /usr/local/lib/valgrind --72132:1:main Getting launcher's name ... --72132:1:main ... /usr/local/bin/valgrind --72132:1:main Get hardware capabilities ... --72132:1:cache Autodetected cache info is sensible --72132:1:cache Cache info: --72132:1:cache #levels = 3 --72132:1:cache #caches = 4 --72132:1:cache cache #0: --72132:1:cache kind = data --72132:1:cache level = 1 --72132:1:cache size = 32768 bytes --72132:1:cache linesize = 64 bytes --72132:1:cache assoc = 8 --72132:1:cache cache #1: --72132:1:cache kind = insn --72132:1:cache level = 1 --72132:1:cache size = 32768 bytes --72132:1:cache linesize = 64 bytes --72132:1:cache assoc = 8 --72132:1:cache cache #2: --72132:1:cache kind = unified --72132:1:cache level = 2 --72132:1:cache size = 262144 bytes --72132:1:cache linesize = 64 bytes --72132:1:cache assoc = 8 --72132:1:cache cache #3: --72132:1:cache kind = unified --72132:1:cache level = 3 --72132:1:cache size = 6291456 bytes --72132:1:cache linesize = 64 bytes --72132:1:cache assoc = 12 --72132:1:main ... arch = X86, hwcaps = x86-mmxext-sse1-sse2 --72132:1:main Getting the working directory at startup --72132:1:main ... /Users/user/cwd --72132:1:main Split up command line --72132:1:main (early_) Process Valgrind's command line options --72132:1:main Create initial image --72132:1:initimg Loading client --72132:1:ume load_thin_file: begin: /opt/local/bin/wine valgrind: mmap-FIXED(0x1000, 1073741824) failed in UME (load_segment2).
Was any previous version of Valgrind able to load Wine on MacOS ? In other words, is this a regression, or is it something you have not tried before?
I have not personally run wine under valgrind on OS X, but the documentation indicates that it was at one time supported: http://wiki.winehq.org/Wine_and_Valgrind#head-9c105724ce981944d64440f57caebd0c24d9f51b
(In reply to Mark Browning from comment #0) > --72132:1:initimg Loading client > --72132:1:ume load_thin_file: begin: /opt/local/bin/wine > valgrind: mmap-FIXED(0x1000, 1073741824) failed in UME (load_segment2). The above looks to mmap 1Gb of memory starting at 0x1000. Seems somewhat strange. Maybe you could try by increasing the aspace mgr min addr using --aspace-minaddr ? (e.g. increase it to 100 MB and/or 500 Mb and/or ..;) and see if that helps ? Is the problem only happening with cachegrind ? (e.G. is --tool=none or --tool=memcheck giving the same) ? Is it working with the previous version of Valgrind ? (3.9 ?) And/or with another version of wine ?
Yes, it happens independent of the tool. Still occurs with --aspace-minaddr=0x40000000. I've also tried running it with an x86 only build of valgrind 3.10, but the same error persists. Here is the memory mapping of wine without running it under valgrind: http://pastebin.com/bwKDJX5P
Interestingly, the WINE_DOS allocation category starts at 0x1000 and is 0x40000000 in length. It looks subdivided, but I'm guessing it was all part of one original allocation.
I changed wine/loader/main.c to only allocate 0x30000000 for this region. My application still works perfectly in wine, and valgrind manages to start up. Now I'm hitting a new error condition in valgrind. I still suspect this mmap-FIXED failure is a valgrind bug, though I don't know enough to say for sure. Thanks for pointing me in the suspicious direction.
It's not so much a bug as a restriction - valgrind has to load itself somewhere and then can't allow a mapping which overlaps that. Normally that can be achieved by just choosing addresses that don't overlap but if a program tries to insist on a fixed address then valgrind may just have to refuse. Fortunately MAP_FIXED is not used very often, not least because it doesn't actually do what most people expect and is, in most cases, very dangerous.
We have another user, Austin, who is testing some Wine-specific patches and will aim to run Wine's unit tests under Valgrind shortly. The result of that testing will be instructive for the status of our Wine support with Valgrind.
Making this a meta bug for Wine issues with Valgrind on OS X.
(In reply to Rhys Kidd from comment #8) > We have another user, Austin, who is testing some Wine-specific patches and > will aim to run Wine's unit tests under Valgrind shortly. > > The result of that testing will be instructive for the status of our Wine > support with Valgrind. With wine-2.1-153-g9c72376, and valgrind-3.13.0.SVN-16222-vex-3303, every Wine unit test fails due to bug 349804. This occurs with 32 and 64-bit Wine.