The testcase also fails on this s390 variant (nightly build):

uname -mrs:        Linux 3.0.101-0.47.52-default s390x
Vendor version:    Welcome to SUSE Linux Enterprise Server 11 SP3 

like so (probably not an assert):

=================================================
./valgrind-new/none/tests/bigcode.stdout.diff
=================================================
--- bigcode.stdout.exp	2015-04-03 04:02:18.000000000 +0200
+++ bigcode.stdout.out	2015-04-03 04:09:19.000000000 +0200
@@ -1,2 +1,2 @@
 mode 1: 20000 copies of f(), 1 reps
-....................result = -37457500
+....................result = 100070000


The s390 box at Marist runs this test OK though:
Linux lfedora1.lf-dev.marist.edu 3.18.7-200.fc21.s390x #1 SMP 

The "community" s390 box also fails:

Linux 2.6.9-42.EL s390x
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)

like the darwin machine

==14390== Nulgrind, the minimal Valgrind tool
==14390== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==14390== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==14390== Command: ./perf/bigcode 1
==14390== 
mode 1: 20000 copies of f(), 1 reps
--14390:0: aspacem segment mismatch: V's seg 1st, kernel's 2nd:
--14390:0: aspacem   7: anon 0004026000-0005325fff     19m -wx-- SmFixed d=0x000 i=0       o=0       (-1,-1) (none)
--14390:0: aspacem ...: .... 0004026000-0005325fff     19m rwx.. ....... d=0x000 i=0       o=0       (.) m=. (none)
--14390:0: aspacem sync check at m_aspacemgr/aspacemgr-linux.c:2087 (vgPlain_am_notify_client_mmap): FAILED
--14390:0: aspacem 
--14390:0: aspacem Valgrind: FATAL: aspacem assertion failed:
--14390:0: aspacem   VG_(am_do_sync_check) (__PRETTY_FUNCTION__,__FILE__,__LINE__)
--14390:0: aspacem   at m_aspacemgr/aspacemgr-linux.c:2087 (vgPlain_am_notify_client_mmap)
--14390:0: aspacem Exiting now.

(In reply to Florian Krohm from comment #1)
> The testcase also fails on this s390 variant (nightly build):
> 
> uname -mrs:        Linux 3.0.101-0.47.52-default s390x
> Vendor version:    Welcome to SUSE Linux Enterprise Server 11 SP3 
> 
> like so (probably not an assert):
> 
> =================================================
> ./valgrind-new/none/tests/bigcode.stdout.diff
> =================================================
> --- bigcode.stdout.exp	2015-04-03 04:02:18.000000000 +0200
> +++ bigcode.stdout.out	2015-04-03 04:09:19.000000000 +0200
> @@ -1,2 +1,2 @@
>  mode 1: 20000 copies of f(), 1 reps
> -....................result = -37457500
> +....................result = 100070000

Before committing, I tested the change on an x86, and amd64 and a ppc64,
so assumed this was relatively well arch independent.
So, either there is a bug, or this test is not arch independent.

> 
> 

> The "community" s390 box also fails:
...
> --14390:0: aspacem segment mismatch: V's seg 1st, kernel's 2nd:
Normally, aspacemgr should have the same image as the kernel.
I think there is a comment in the darwin code that tells that it is normal
that these diverges on Darwin.
It is also normal that it diverges for an 'inner' valgrind (as it cannot observe the mmap
done by the outer).

But a divergence on linux seems suspicious.

Philippe

(In reply to Philippe Waroquiers from comment #2)
> I think there is a comment in the darwin code that tells that it is normal
> that these diverges on Darwin.
See e.g. aspacemgr-linux.c:867 with the comment
   /* GrP fixme not */
See also other #ifdef darwin or comments mentionning darwin or search for kludge.

So, on darwin, it looks "normal" to have aspacemgr and kernel desynchronised.

I looked at the s390 failure:

-14390:0: aspacem segment mismatch: V's seg 1st, kernel's 2nd:
--14390:0: aspacem   7: anon 0004026000-0005325fff     19m -wx-- SmFixed d=0x000 i=0       o=0       (-1,-1) (none)
--14390:0: aspacem ...: .... 0004026000-0005325fff     19m rwx.. ....... d=0x000 i=0       o=0       (.) m=. (none)

The mismatch occurs because the protection is different. Valgrind thinks is "wx" kernel says "rwx".
This error occurs for the call in bigcode.c:
   char* a = mmap(0, FN_SIZE * n_fns, 
                     PROT_EXEC|PROT_WRITE, 
                     MAP_PRIVATE|MAP_ANONYMOUS, -1,0);

which explains why valgrind thinks it "wx".
Looking at the mmap manpage on that s390 box, it seems that it is perfectly valid for the kernel to give "rwx" protection to the mapped space given the request above:

    An  implementation [of mmap]  may permit accesses other than those specified by prot;  ...

and then some lengthy explanation of what the kernel may or may not do to the protection.
I'm not sure whether this behaviour is allowed in general or is special for s390. Any opinions ?

So, in essence, I think that the check in aspacemgr-linux.c needs adjusting and that's it.
Something similar to what has been done with sloppyXcheck...

Created attachment 91910 [details]
proposed patch

Here's the page that says that mmap may grant more permissions than being asked for.
http://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.html
I do not know why the linux specific man pages do not mention it
http://man7.org/linux/man-pages/man2/mmap.2.html

Anyhow the patch here changes the permission check such that the permissions granted by the kernel are at least those being asked for.
Regtested on x86-64, s390, ppc64 with no new failures.

Well, on s390 hw-wise x implies r. Seems that some kernels (or glibc?) will
change -wx to rwx (SLES11) and others (3.19) will still show -wx in /proc/*/maps.

I cant find a suspicious commit in the kernel that explains the change in behaviour, maybe its
a glibc change or config option or whatever.

It should be easy enough to tell if glibc is tweaking the flags - just use strace to see what flags are really passed to the kernel when you do an mmap with PROT_EXEC but no PROT_READ.

(In reply to Tom Hughes from comment #7)
> It should be easy enough to tell if glibc is tweaking the flags - just use
> strace to see what flags are really passed to the kernel when you do an mmap
> with PROT_EXEC but no PROT_READ.

Right.. glibc does not tweak anything as strace reveals this:

mmap(NULL, 4980000, PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)

i.e. permission flags unchanged. So it's the kernel who's doing the tweaking.
I'm going to apply the following patch which on s390 ensures that wx and rwx permissions compare equal.

Created attachment 91935 [details]
patch for s390

Patch looks OK to me.

(In reply to Julian Seward from comment #10)
> Patch looks OK to me.

That patch has already gone in as r15075 on Apr 7.
I think this bug is waiting for Rhys to look at the OS X failure.

Resolved for OS X in r15171.