Bug 365258

Summary: Reading syms from /valgrind/lib/valgrind/memcheck-arm-linux bject doesn't have a dynamic symbol table
Product: [Developer tools] valgrind Reporter: rudici.cazeao
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED NOT A BUG    
Severity: major CC: rudici.cazeao, tom
Priority: NOR    
Version First Reported In: 3.11.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Valgrind Output

Description rudici.cazeao 2016-07-08 22:14:34 UTC
==1688== Memcheck, a memory error detector
==1688== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1688== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1688== Command: ./ltel1
==1688== 
--1688-- Valgrind options:
--1688--    -v
--1688-- Contents of /proc/version:
--1688--   Linux version 3.0.51-rt75 (litepoint@rcazeao-o9020ub) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #2 SMP P
REEMPT RT Wed May 25 14:41:22 PDT 2016
--1688-- 
--1688-- Arch and hwcaps: ARM, LittleEndian, ARMv7
--1688-- Page sizes: currently 4096, max supported 4096
--1688-- Valgrind library directory: /usr/sbin/valgrind/lib/valgrind
--1688-- Reading syms from /armlp/lte/fdd/phy/ltel1
--1688-- warning: DiCfSI 0x0 .. 0x3 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x13 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x13 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x2f outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x7 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x7 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x0 .. 0x7 outside mapped rx segments (NONE)
--1688-- warning: DiCfSI 0x8 .. 0x17 outside mapped rx segments (NONE)
--1688-- Reading syms from /lib/ld-2.11.1.so
--1688-- Reading syms from /usr/sbin/valgrind/lib/valgrind/memcheck-arm-linux
--1688--    object doesn't have a dynamic symbol table
--1688-- Scheduler: using generic scheduler lock implementation.
--1688-- Reading suppressions file: /usr/sbin/valgrind/lib/valgrind/default.supp
==1688== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-1688-by-root-on-???
==1688== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-1688-by-root-on-???
==1688== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-1688-by-root-on-???
==1688== 
==1688== TO CONTROL THIS PROCESS USING vgdb (which you probably
==1688== don't want to do, unless you know exactly what you're doing,
==1688== or are doing some strange experiment):
==1688==   /usr/sbin/valgrind/lib/valgrind/../../bin/vgdb --pid=1688 ...command...
==1688== 
==1688== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==1688==   /path/to/gdb ./ltel1
==1688== and then give GDB the following command
==1688==   target remote | /usr/sbin/valgrind/lib/valgrind/../../bin/vgdb --pid=1688
==1688== --pid is optional if only one valgrind process is running
==1688== 
==1688== 
==1688== Process terminating with default action of signal 4 (SIGILL): dumping core
==1688==  Illegal opcode at address 0x38086DFC
==1688==    at 0x40007A0: ??? (in /lib/ld-2.11.1.so)
==1688== 
==1688== HEAP SUMMARY:
==1688==     in use at exit: 0 bytes in 0 blocks
==1688==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1688== 
==1688== All heap blocks were freed -- no leaks are possible
==1688== 
==1688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==1688== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

Reproducible: Always

Steps to Reproduce:
1. Compile valgrind 3.11.0 source code
2. Comment out "add_hardwire_spec("ld-linux.so.3", "memcpy")  in coregrind/m_redir.c
3. Execute "valgrind -v ./app_name

Actual Results:  
==1688== Process terminating with default action of signal 4 (SIGILL): dumping core
==1688==  Illegal opcode at address 0x38086DFC
==1688==    at 0x40007A0: ??? (in /lib/ld-2.11.1.so

Expected Results:  
I was expecting valgrind to detect memory leaks in app_name
Comment 1 Tom Hughes 2016-07-08 22:43:48 UTC
Well it's statically linked so of course it doesn't have a dynamic symbol table.

I don't understand what that has to do with the illegal instruction though? or why you decided to comment out that line?
Comment 2 rudici.cazeao 2016-07-08 22:52:12 UTC
Thanks for your prompt reply.
I decided to comment out that line because initially I was experiencing the following:

"Fatal error at startup: a function redirection which is mandatory for this platform-tool combination cannot be set up. Details of the the redirection are:

A must-be-redirected function whose name matches the patter: strcmp is an object with soname matching : ld-linux.so.3 was not found whilst processing symbols from the object with soname: ld-linux.so.3.
....
Cannot contineue --exiting now. Sorry"

Might my change explain why I'm getting the illegal instruction?

By the way, I hope I'm not sounding unintelligent but I have to ask "how do I insure that memcheck-arm-linux is not statically linked" to avoid the dynamic symbol table table error.
Comment 3 Tom Hughes 2016-07-08 23:58:17 UTC
That's not an error, it's just an informational message. There is no way to dynamically link that file.

When valgrind says the redirection is mandatory it does so for a very good reason, and you can't just comment out the line to stop it complaining!

You need to install debug symbols for glibc, or stop it being stripped, or something.
Comment 4 rudici.cazeao 2016-07-13 16:28:47 UTC
Created attachment 100069 [details]
Valgrind Output

This is the output based on the following:
1) using a non-stripped version of ld-2.11.1.so.
Comment 5 rudici.cazeao 2016-07-13 16:32:51 UTC
Hi Tom,
Would you mind looking into the attachment "attachment 100069 [details]" ?
Also,
This is the only configuration that seems to build on my machine:
 ./configure --target=arm-none-linux-gnueabi --host=arm-linux-gnueabi --prefix=/usr/sbin/valgrind CFLAGS=-static.

Yet, "uname -a' command on my build machine yields the following:
"Linux rcazeao-o9020ub 3.13.0-62-generic #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux".
What should "--host" be set to?
Comment 6 Julian Seward 2016-09-14 14:36:40 UTC
(In reply to rudici.cazeao from comment #5)
> What should "--host" be set to?

I think you have it set correctly.  But you need to remove CFLAGS=-static and
basically forget about changing the linking arrangements.  They are how they are
for good reasons ;-)

The more significant part here is the illegal instruction.  This is a failure in
the code generated by Valgrind itself.  About the only way we can help you is
if you can catch the SIGILL in a debugger (GDB) and show what instruction
that is.

What CPU is this?  Is it NEON capable?
Comment 7 Julian Seward 2016-09-14 14:54:58 UTC
*** Bug 365686 has been marked as a duplicate of this bug. ***