This is on an ARM system. The error I get is: ==1032== Invalid read of size 1 ==1032== at 0x4830D4C: strncmp (mc_replace_strmem.c:547) ==1032== by 0x6A048B3: have_feature (pixman-arm.c:167) ==1032== by 0x6A0494D: _pixman_arm_get_implementations (pixman-arm.c:210) ==1032== by 0x6A0FC9F: _pixman_choose_implementation (pixman-implementation.c:367) ==1032== by 0x69DED55: pixman_constructor (pixman.c:39) ==1032== by 0x400B02B: call_init (dl-init.c:84) ==1032== by 0x400B0AB: _dl_init (dl-init.c:133) ==1032== by 0x4000C61: ??? (in /lib/arm-linux-gnueabihf/ld-2.17.so) ==1032== Address 0xbee26640 is not stack'd, malloc'd or (recently) free'd I'm not sure whether this bug is from valgrind or libpixman. Please advise. On Intel-based systems there is no valgrind error.
This is just reporting a problem in libpixman, so unless you have some evidence this is a false positive you should be addressing it with them. As it is clearly ARM specific code in pixman (see _pixman_arm_get_implementations in the stack) obviously it wouldn't trigger on other platforms.
I think this is actually a bug in V. I remember seeing it in the libpixman that is inside Firefox. Something to do with pixman validly doing strncmp on some string that is part of the AT_ entries on the stack at startup. That V (on arm-linux) doesn't know is validly accessible. I don't remember any more details.
Reopening, since I believe this is a Valgrind bug.
Hmm. Any AT entries that point to something normally point to other data in the same area of the stack, but maybe ARM does something odd here?
So that line in pixman-arm.c is, as you saying, doing a strncmp on AT_PLATFORM to see what ARM architecture it is dealing with. It's actually doing it by reading /proc/self/auxv rather than just by looking at the auxv on the stack for some reason. Presumably the addresses it sees in the auxv value will still be on the stack though?!?
So create_elf_tables in fs/binfmt_elf.c in the kernel copies the platform string to the client stack and sets AT_PLATFORM to point to it, so the address ought to be on the client stack... The problem is that our launcher (in initimg-linux.c) then copies the auxilliary vector to the stack for the emulated client, copying the AT_PLATFORM string as well and adjusting it's pointer. But by using /proc/self/auxv to access the auxilliary vector pixman is seeing the original pointer, not the adjusted one. So the address it sees points at the real stack the kernel provided, not the one we setup. I thought there was another bug complaining about us not emulating /proc/self/auxv but I can't find it right now.
The fake /proc/self/auxv bug was bug ##253519 that got applied as r13019.
So it sounds like this was fixed in 3.9.0 then... *** This bug has been marked as a duplicate of bug 253519 ***