| Summary: | vgpreload is not friendly to 64->32 bit execs, gives ld.so warnings | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Timur Iskhodzhanov <timurrrr> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | philippe.waroquiers, tom |
| Priority: | NOR | ||
| Version: | 3.7 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | fix VG_(env_remove_valgrind_env_stuff) | ||
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. 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.
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. 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. 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. > 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.
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.
Fixed in rev 12287 Thanks for fixing this! |
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?