1) os: Linux yyyyy 2.6.35 #11 SMP PREEMPT Thu May 16 16:33:16 CST 2013 armv7l GNU/Linux 2) valgrind version: Current release: valgrind-3.8.1 3) build configure: ./configure --prefix==$(pwd)../build --host=armv7a_xxxx451_001_vfp-linux-gnueabi 4) valgrind command log: (130517_20:38:40.128)VALGRIND_LIB=/mnt/sda1/valgrind/lib/valgrind (130517_20:38:40.128)/mnt/sda1/valgrind/bin/valgrind -v --leak-check=full /mnt/sda1/sysroot/ld-2.12.2.so /mnt/sda1/app -Q source_type= -jz -T 7 5) valgrind output: (130517_20:38:40.206)==1071== Memcheck, a memory error detector (130517_20:38:40.206)==1071== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. (130517_20:38:40.206)==1071== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info (130517_20:38:40.206)==1071== Command: /mnt/sda1/sysroot/ld-2.12.2.so /mnt/sda1/app -Q source_type= -jz -T 7 (130517_20:38:40.206)==1071== (130517_20:38:40.206)--1071-- Valgrind options: (130517_20:38:40.206)--1071-- -v (130517_20:38:40.206)--1071-- --leak-check=full (130517_20:38:40.206)--1071-- Contents of /proc/version: (130517_20:38:40.206)--1071-- Linux version 2.6.35 (xxxx@yyyslx03) (gcc version 4.5.1 (GCC) ) #11 SMP PREEMPT Thu May 16 16:33:16 CST 2013 (130517_20:38:40.206)--1071-- Arch and hwcaps: ARM, ARMv7-vfp (130517_20:38:40.206)--1071-- Page sizes: currently 4096, max supported 4096 (130517_20:38:40.206)--1071-- Valgrind library directory: /mnt/sda1/valgrind/lib/valgrind (130517_20:38:40.206)--1071-- Reading syms from /mnt/sda1/sysroot/ld-2.12.2.so (130517_20:38:40.206)--1071-- Reading syms from /mnt/sda1/valgrind/lib/valgrind/memcheck-arm-linux (130517_20:38:40.206)--1071-- object doesn't have a dynamic symbol table (130517_20:38:40.284)--1071-- Scheduler: using generic scheduler lock implementation. (130517_20:38:40.284)--1071-- Reading suppressions file: /mnt/sda1/valgrind/lib/valgrind/default.supp (130517_20:38:40.362)==1071== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-1071-by-???-on-??? (130517_20:38:40.362)==1071== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-1071-by-???-on-??? (130517_20:38:40.362)==1071== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-1071-by-???-on-??? (130517_20:38:40.362)==1071== (130517_20:38:40.362)==1071== TO CONTROL THIS PROCESS USING vgdb (which you probably (130517_20:38:40.362)==1071== don't want to do, unless you know exactly what you're doing, (130517_20:38:40.362)==1071== or are doing some strange experiment): (130517_20:38:40.362)==1071== /mnt/sda1/valgrind/lib/valgrind/../../bin/vgdb --pid=1071 ...command... (130517_20:38:40.362)==1071== (130517_20:38:40.362)==1071== TO DEBUG THIS PROCESS USING GDB: start GDB like this (130517_20:38:40.362)==1071== /path/to/gdb /mnt/sda1/sysroot/ld-2.12.2.so (130517_20:38:40.362)==1071== and then give GDB the following command (130517_20:38:40.362)==1071== target remote | /mnt/sda1/valgrind/lib/valgrind/../../bin/vgdb --pid=1071 (130517_20:38:40.362)==1071== --pid is optional if only one valgrind process is running (130517_20:38:40.362)==1071== (130517_20:38:40.362)--1071-- REDIR: 0x11ec00 (memcpy) redirected to 0x380443d0 (???) (130517_20:38:40.440)--1071-- REDIR: 0x11e050 (strlen) redirected to 0x380443a4 (???) (130517_20:38:40.893)disInstr(arm): unhandled instruction: 0x69746E65 (130517_20:38:40.893) cond=6(0x6) 27:20=151(0x97) 4:4=0 3:0=5(0x5) (130517_20:38:40.893)disInstr(arm): unhandled instruction: 0x69746E65 (130517_20:38:40.893) cond=6(0x6) 27:20=151(0x97) 4:4=0 3:0=5(0x5) (130517_20:38:40.893)==1071== Invalid read of size 1 (130517_20:38:40.893)==1071== at 0x11DB14: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== by 0x10E05F: ??? (dl-load.c:1241) (130517_20:38:40.893)==1071== by 0x10FB53: ??? (dl-load.c:2247) (130517_20:38:40.893)==1071== by 0x10B087: ??? (rtld.c:1067) (130517_20:38:40.893)==1071== by 0x11BDCB: ??? (dl-sysdep.c:244) (130517_20:38:40.893)==1071== by 0x10C33F: ??? (rtld.c:334) (130517_20:38:40.893)==1071== by 0x10C59B: ??? (rtld.c:562) (130517_20:38:40.893)==1071== by 0x10878F: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== Address 0x812 is not stack'd, malloc'd or (recently) free'd (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== Process terminating with default action of signal 11 (SIGSEGV) (130517_20:38:40.893)==1071== Access not within mapped region at address 0x812 (130517_20:38:40.893)==1071== at 0x11DB14: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== by 0x10E05F: ??? (dl-load.c:1241) (130517_20:38:40.893)==1071== by 0x10FB53: ??? (dl-load.c:2247) (130517_20:38:40.893)==1071== by 0x10B087: ??? (rtld.c:1067) (130517_20:38:40.893)==1071== by 0x11BDCB: ??? (dl-sysdep.c:244) (130517_20:38:40.893)==1071== by 0x10C33F: ??? (rtld.c:334) (130517_20:38:40.893)==1071== by 0x10C59B: ??? (rtld.c:562) (130517_20:38:40.893)==1071== by 0x10878F: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== If you believe this happened as a result of a stack (130517_20:38:40.893)==1071== overflow in your program's main thread (unlikely but (130517_20:38:40.893)==1071== possible), you can try to increase the size of the (130517_20:38:40.893)==1071== main thread stack using the --main-stacksize= flag. (130517_20:38:40.893)==1071== The main thread stack size used in this run was 8388608. (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== HEAP SUMMARY: (130517_20:38:40.893)==1071== in use at exit: 0 bytes in 0 blocks (130517_20:38:40.893)==1071== total heap usage: 0 allocs, 0 frees, 0 bytes allocated (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== All heap blocks were freed -- no leaks are possible (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== 1 errors in context 1 of 1: (130517_20:38:40.893)==1071== Invalid read of size 1 (130517_20:38:40.893)==1071== at 0x11DB14: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== by 0x10E05F: ??? (dl-load.c:1241) (130517_20:38:40.893)==1071== by 0x10FB53: ??? (dl-load.c:2247) (130517_20:38:40.893)==1071== by 0x10B087: ??? (rtld.c:1067) (130517_20:38:40.893)==1071== by 0x11BDCB: ??? (dl-sysdep.c:244) (130517_20:38:40.893)==1071== by 0x10C33F: ??? (rtld.c:334) (130517_20:38:40.893)==1071== by 0x10C59B: ??? (rtld.c:562) (130517_20:38:40.893)==1071== by 0x10878F: ??? (in /mnt/sda1/sysroot/ld-2.12.2.so) (130517_20:38:40.893)==1071== Address 0x812 is not stack'd, malloc'd or (recently) free'd (130517_20:38:40.893)==1071== (130517_20:38:40.893)==1071== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Reproducible: Always Steps to Reproduce: 1) run app thru ld-2.12.2.so thru valgrind
I've confirmed it was caused by my error using this great tool. 1)As my last post, (130517_20:38:40.128)/mnt/sda1/valgrind/bin/valgrind -v --leak-check=full /mnt/sda1/sysroot/ld-2.12.2.so /mnt/sda1/app -Q source_type= -jz -T 7 I involke my app like this: valgrind ld-linux.so app. (ld-linux.so is a version not stripped, located in my removable disk) 2)I rebuild my app with -W--dynamic-linker=/my/not-stripped/ld-linux.so, and the problem i reported was resolved. 3)however i can still not use valgrind to debug my app, because valgrind requires more memory space than our hw system. Anyway, this bug can be closed now.