Bug 262390

> uname -a
Darwin MacBook.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

This happens with all executables. Only the second argument of mmap changes.
When I changed the function check_mmap in coregrind/m_ume/macho.c to print more info:

static void check_mmap(SysRes res, Addr base, SizeT len, HChar* who)
{
   if (sr_isError(res)) {
      VG_(printf)("valgrind: mmap(0x%llx, %lld) failed in UME (%s, errno=%llx, is-error=%llx).\n",
                  (ULong)base, (Long)len, who,
                  (ULong)sr_Res(res), (ULong)sr_isError(res));
      VG_(exit)(1);
   }
}

I get this:
> ~/valgrind-3.6.0/bin/valgrind /bin/ls
valgrind: mmap(0x1000, 20480) failed in UME (load_segment1, errno=0, is-error=1).

So there is no errno, but SysRes is still labeled as error which looks wrong to me, but this isn't the major point here.

Adding more printouts to VG_(am_mmap_named_file_fixed_client) in coregrind/m_aspacemgr/aspacemgr-linux.c I learned that VG_(mk_SysRes_Error) was called with VKI_EINVAL after the failure of the function VG_(am_get_advisory).
At this point ok=0 start=0x1000 advised=0x0.

So VG_(am_get_advisory) failed.

Adding some more printouts in the VG_(am_get_advisory) function in the same module I learned that it fails near the line "Not acceptable.  Fail." In the section "Implement Policy Exception #1" inside cycle nsegments[i].kind==2 causes failure. 2 corresponds to SkAnonV and only acceptable values, according to the code, are SkFree,SkFileC,SkAnonC,SkShmC,SkResvn. Right before that cycle values were like this:
reqStart=0x1000 reqEnd=0x5fff iLo=1 iHi=0x1

Do you know where do I go from here?

The svn trunk from valgrind.org compiled worked just fine for me
on 10.6.5 built with XCode 3.2.5 just a couple of days ago.  Can
you try that?

Urr.  This isn't one of those binaries with a nonstandard load address
of below 4G, is it?

I am getting the same with the current trunk (rev.11496).

No, this happens with all executables I tried. Particularly with /bin/ls, /bin/cat.

Are you sure you are trying on 32-bit MacOS? Maybe 64-bit is different, I can't check.

I am building with just gmake. Shouldn't make any difference.

So what should I be looking for? Why would SkAnonV segment get into nsegments and cause VG_(am_get_advisory) to fail?

Any ideas what could be wrong?

I see the same on OS X 10.6.6:

  $ valgrind --version
  valgrind-3.6.0
  $ valgrind /usr/bin/true 
  valgrind: mmap(0x100000000, 4096) failed in UME (load_segment1).

However, running as the superuser seems to work around the issue:

  $ sudo !!
  sudo valgrind /usr/bin/true 
  Password:
  ==65172== Memcheck, a memory error detector
  ==65172== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
  ==65172== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
  ==65172== Command: /usr/bin/true
  [etc]

I can confirm this bug. I installed the valgrind-3.6.0, which is supposed to work on “X86/Darwin and AMD64/Darwin (Mac OS X 10.5 and 10.6)”. I compiled with a simple “./configure --prefix=/opt/valgrind && make && make install”. My system is Snow Leopard (OS 10.6.6) with XCode 3.2.5:

$ uname -a
Darwin lumo.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)


I get the same error with any executable, either 32 or 64-bit:

$ valgrind /bin/ls
valgrind: mmap(0x100000000, 24576) failed in UME (load_segment1).


As noted by another user, it works when used with sudo: “sudo valgrind /bin/ls”

I can confirm this with current SVN trunk (revision 11539). After the checkout, I did:
./configure --prefix=/opt/valgrind-svn-11539 && make && make install

It may or may not be related, but “make check” fails with:


gcc -DHAVE_CONFIG_H -I. -I../../..  -I../../.. -I../../../include -I../../../coregrind -I../../../include -I../../../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1  -Winline -Wall -Wshadow -g -m64 -Wno-long-long  -Wno-pointer-sign -fno-stack-protector -MT fxsave-amd64.o -MD -MP -MF .deps/fxsave-amd64.Tpo -c -o fxsave-amd64.o fxsave-amd64.c
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:186:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:186:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:188:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:188:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:190:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:190:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:192:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:192:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:194:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:194:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:196:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:196:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:198:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:198:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:200:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:200:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:202:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:202:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:204:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:204:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:206:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:206:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:208:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:208:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:210:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:210:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:212:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:212:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:214:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:214:cannot do signed 4 byte relocation
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:216:32-bit absolute addressing is not supported for x86-64
/var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc2oH6Nt.s:216:cannot do signed 4 byte relocation
make[5]: *** [fxsave-amd64.o] Error 1
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check-recursive] Error 1
make[1]: *** [check-recursive] Error 1
make: *** [check] Error 2

Created attachment 57208 [details]
Output of configure (for trunk)

Created attachment 57209 [details]
Output of make (for trunk)

(In reply to comment #10)
> It may or may not be related, but “make check” fails with:

This is known about, but unrelated.

I'd like to fix this, but understand that that can't happen until you
figure out a way to demonstrate it on a vanilla install of 10.6.x.
3.6.0, 3.6.1 and trunk work just fine for me on 10.6.x, and, I
suspect, for most other people -- else we'd be flooded with reports
like this.  So the question is, how does your setup differ from
"normal" ?

Require: test case + instructions to reproduce.

So it appears that once again, the issue is the interaction of valgrind with Instant Hijack, which is installed alongside the Airfoil software from Rogue Amoeba:

lumo ~/Downloads $ valgrind /bin/ls
valgrind: mmap(0x100000000, 24576) failed in UME (load_segment1).
lumo ~/Downloads $ sudo /usr/local/hermes/bin/hermesctl unload
lumo ~/Downloads $ valgrind /bin/ls 2>&1 | head -n 4
==83073== Memcheck, a memory error detector
==83073== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==83073== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==83073== Command: /bin/ls

So, it seems that Instant Hijack 2.2.8, part of Airfoil 3.5.4, is incompatible with valgrind 3.6.0 on Snow Leopard. This already happened in the past, as can be seen in the release notes for Airfoil (http://www.rogueamoeba.com/airfoil/mac/releasenotes.php). I don't know whose fault it is, this time!

sudo /usr/local/hermes/bin/hermesctl unload
fixed it for me too.

You should at the very least add this to HOWTO for MacOS.

I think you don't need test case + instructions any more, therefore I change it back to UNCONFIRMED.

I have something called Audio Hijack installed, and it I suspect caused this /usr/local/hermes/bin/hermesctl to be loaded by default. Though I don't know exactly why.

In the other thread that picked up issues with Valgrind + InstantHijack, their developer noted that there were some pre-release versions, in mid 2009, which avoided the crashes.

https://bugs.kde.org/show_bug.cgi?id=193917

Are you able to confirm if the version of Instant Hijack you see here is prior to that release? If not, there is a simple path to resolve this crash via app update.

Sorry, I don't use MacOS any more.
Maybe someone who does can do this, or just close this bug.

Resolved with an update to the third party application.