Bug 319968

Summary:	[arm]disInstr(arm): unhandled instruction: 0x69746E65 (valgrind_v3.81, cortex-A9)
Product:	[Developer tools] valgrind	Reporter:	wgq2633 <wgq2633>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED NOT A BUG
Severity:	grave	CC:	wgq2633
Priority:	NOR
Version First Reported In:	3.8.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description wgq2633 2013-05-18 03:52:44 UTC

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

Comment 1 wgq2633 2013-06-06 14:41:20 UTC

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.