Re: [Valgrind-users] Problem in getting valgrind to run on android

[John R. <jr...@Bi...>]

> Few dynamically loaded libraries were statically linked to few other libraries.   After converting them to dynamic libraries, I am closer to detect memory problems.   Also, I had to turn on -g and avoid stripping the executable to get an accurate detection
> 
> However, this still dazzles me:
> 
> I still get this warning while running valgrind:
> --8925--   Considering /system/lib/libc.so ..
> --8925--   .. CRC mismatch (computed aedb52cb wanted eadc3e5a)
> --8925--    object doesn't have a symbol table
> 
> When I compute crc for /system/lib/libc.so externally, I get aedb52cb and the system under test doesn't contain libc anywhere else..  Where else is the executable picking libc from?  Output of strace relevant to libc given below

I don't know exactly.  grep'ping the valgrind source code for "CRC mismatch"
shows  coregrind/m_debuginfo/readelf.c  function open_debug_file() which is
called from find_debug_file() which is called from "Bool ML_(read_elf_debug_info)".
read_elf_debug_info() gets the "wanted" crc:
            /* Extract the CRC from the debuglink section */
            UInt crc = ML_(img_get_UInt)(debuglink_escn.img,
                                         debuglink_escn.ioff + crc_offset);
So run memcheck under a debugger, put a breakpoint there, look at the
traceback, and determine which debuglink section is being examined.

One common problem is "crosslinking": building the executable main program
on a different machine, especially one with a different hardware architecture,
such as building an ARM executable using a x86* development environment.
The two libc.so must match in order that valgrind sees the right symbols,
but it is easy for the target machine and the build machine
to get out-of-sync: one gets updated but not the other.