Bug 286270 - vgpreload is not friendly to 64->32 bit execs, gives ld.so warnings
Summary: vgpreload is not friendly to 64->32 bit execs, gives ld.so warnings
Status: VERIFIED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.7 SVN
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-10 14:41 UTC by Timur Iskhodzhanov
Modified: 2011-12-14 08:38 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
fix VG_(env_remove_valgrind_env_stuff) (1.50 KB, text/plain)
2011-11-26 21:15 UTC, Philippe Waroquiers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur Iskhodzhanov 2011-11-10 14:41:21 UTC
Repro:
$ cat 64.cpp 
#include <unistd.h>
int main() { execlp("./32", "./32", NULL); }

timurrrr@timurrrr:~/valgrind_bugs/64vs32bits$ cat 32.cpp 
int main() { }

timurrrr@timurrrr:~/valgrind_bugs/64vs32bits$ g++ 64.cpp -o 64
timurrrr@timurrrr:~/valgrind_bugs/64vs32bits$ g++ -m32 32.cpp -o 32
timurrrr@timurrrr:~/valgrind_bugs/64vs32bits$ valgrind --trace-children=yes ./64
...
==13921== Command: ./64
...
==13921== Command: ./32
ERROR: ld.so: object '.../lib/valgrind/vgpreload_core-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '.../valgrind/vgpreload_memcheck-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
...

AFAIU, this may result in missing memcpy wrappers?
Comment 1 Tom Hughes 2011-11-10 14:53:37 UTC
I think there's something wrong with your setup - the LD_PRELOAD should be stripped by VG_(env_remove_valgrind_env_stuff) before the exec happens and then the launcher will add back an appropriate preload for the child as it starts the child.
Comment 2 Timur Iskhodzhanov 2011-11-10 14:58:17 UTC
Tom,
did you try to run the reproducers?
This is also happening on Chromium bots which are pretty standard Ubuntu Lucid.

Hm, looks like memcpy et al. ARE wrapped:
$ cat 32.cpp 
#include <string.h>
int main() {
  char buff[16];
  memcpy(buff, buff+1, 15);
}

$ valgrind --trace-children=yes -v ./64
--14889-- REDIR: 0x4416e80 (strlen) redirected to 0x38043b68 (vgPlain_x86_linux_REDIR_FOR_strlen)
--14889-- REDIR: 0x4416cb0 (index) redirected to 0x38043b43 (vgPlain_x86_linux_REDIR_FOR_index)
--14889-- Reading syms from .../lib/valgrind/vgpreload_core-x86-linux.so (0x4b0a000)
--14889-- Reading syms from .../lib/valgrind/vgpreload_memcheck-x86-linux.so (0x4b0e000)
ERROR: ld.so: object '.../lib/valgrind/vgpreload_core-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '.../lib/valgrind/vgpreload_memcheck-amd64-linux.so' from LD_PRELOAD cannot be preloaded: ignored.
...
--14889-- REDIR: 0x702b7e0 (rindex) redirected to 0x4b12060 (rindex)
--14889-- REDIR: 0x702cbf0 (memcpy) redirected to 0x4b0a44c
(_vgnU_ifunc_wrapper)
--14889-- REDIR: 0x70c96c0 (__memcpy_ssse3) redirected to 0x4b13140 (memcpy)
==14889== Source and destination overlap in memcpy(0xfecea44c, 0xfecea44d, 15)
==14889==    at 0x4B131B3: memcpy (mc_replace_strmem.c:838)
==14889==    by 0x8048557: main (in /home/timurrrr/valgrind_bugs/64vs32bits/32)

Still, the "ld.so" warning is not very friendly.
Comment 3 Julian Seward 2011-11-10 15:10:41 UTC
I suspect Timur is right.  I've seen the same messages recently although
I didn't investigate.  I think it might have been when running regtests
on x86_64-linux, but when the system is built 32-bit only.
Comment 4 Julian Seward 2011-11-10 15:14:47 UTC
I should add, perhaps this is a regression caused by the redir overhaul
that happened a couple of months as a result of the memcpy/memmove swamp.
I don't seem to remember it happening before that.  So we should investigate.
Comment 5 Tom Hughes 2011-11-10 15:27:54 UTC
I was just trying to provide some clues as to how it is supposed to work, as I know Timur is up to digging around in valgrind to see what is going wrong.
Comment 6 Timur Iskhodzhanov 2011-11-11 20:37:33 UTC
> I know Timur is up to digging around in valgrind to see what is going wrong.
Not very much this time. I don't know of any issues it causes to me yet except for the annoying warning line.
Comment 7 Philippe Waroquiers 2011-11-26 21:15:21 UTC
Created attachment 66106 [details]
fix VG_(env_remove_valgrind_env_stuff) 

rev 12001 has introduced a regression in VG_(env_remove_valgrind_env_stuff):
to avoid modifying a possibly read-only env string, the string is duplicated,
and the copy is modified. However, mash_env_column modifies the string
"in-place". The modified string was not put back in the env (and could not,
because the src string is only partially copied).

The attached patch fixes the problem.
Comment 8 Philippe Waroquiers 2011-12-11 16:38:32 UTC
Fixed in rev 12287
Comment 9 Timur Iskhodzhanov 2011-12-14 08:38:36 UTC
Thanks for fixing this!