Bug 262390 - valgrind fails with the message: mmap(0x1000, 4096) failed in UME (load_segment1)
Summary: valgrind fails with the message: mmap(0x1000, 4096) failed in UME (load_segme...
Status: RESOLVED INTENTIONAL
Alias: None
Product: valgrind
Classification: Unclassified
Component: general (show other bugs)
Version: 3.6.0
Platform: MacPorts Packages macOS
: NOR major (vote)
Target Milestone: ---
Assignee: Rhys Kidd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-07 10:40 UTC by Yuri
Modified: 2015-07-04 03:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Output of configure (for trunk) (10.45 KB, text/plain)
2011-02-13 13:36 UTC, FX
Details
Output of make (for trunk) (377.87 KB, text/plain)
2011-02-13 13:36 UTC, FX
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri 2011-01-07 10:40:15 UTC
All executables on MacOS 10.6.5 fail with the same message:
valgrind: mmap(0x1000, 4096) failed in UME (load_segment1).

valgrind is from macports: valgrind-3.6.0
Comment 1 Yuri 2011-01-07 10:41:12 UTC
> 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
Comment 2 Yuri 2011-01-08 08:25:44 UTC
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?
Comment 3 Julian Seward 2011-01-11 00:47:08 UTC
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?
Comment 4 Julian Seward 2011-01-11 00:48:01 UTC
Urr.  This isn't one of those binaries with a nonstandard load address
of below 4G, is it?
Comment 5 Yuri 2011-01-11 22:36:46 UTC
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.
Comment 6 Yuri 2011-01-11 22:37:44 UTC
I am building with just gmake. Shouldn't make any difference.
Comment 7 Yuri 2011-01-15 11:43:00 UTC
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?
Comment 8 jds 2011-02-04 12:56:22 UTC
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]
Comment 9 FX 2011-02-13 13:26:04 UTC
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”
Comment 10 FX 2011-02-13 13:29:50 UTC
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
Comment 11 FX 2011-02-13 13:36:10 UTC
Created attachment 57208 [details]
Output of configure (for trunk)
Comment 12 FX 2011-02-13 13:36:51 UTC
Created attachment 57209 [details]
Output of make (for trunk)
Comment 13 Julian Seward 2011-02-16 13:29:37 UTC
(In reply to comment #10)
> It may or may not be related, but “make check” fails with:

This is known about, but unrelated.
Comment 14 Julian Seward 2011-02-16 13:32:05 UTC
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" ?
Comment 15 Julian Seward 2011-02-16 13:36:41 UTC
Require: test case + instructions to reproduce.
Comment 16 FX 2011-02-16 13:54:42 UTC
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!
Comment 17 Yuri 2011-02-19 22:40:44 UTC
sudo /usr/local/hermes/bin/hermesctl unload
fixed it for me too.

You should at the very least add this to HOWTO for MacOS.
Comment 18 Yuri 2011-02-19 22:44:42 UTC
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.
Comment 19 Rhys Kidd 2015-05-19 06:40:12 UTC
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.
Comment 20 Yuri 2015-05-19 06:50:24 UTC
Sorry, I don't use MacOS any more.
Maybe someone who does can do this, or just close this bug.
Comment 21 Rhys Kidd 2015-07-04 03:54:08 UTC
Resolved with an update to the third party application.