|
From: Kacper K. <kac...@gm...> - 2017-09-06 11:29:17
|
Openwrt does not have lscpu command available (nor in any package). cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 132.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10 processor : 1 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 132.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10 Hardware : Freescale i.MX6 Quad/DualLite (Device Tree) Revision : 0000 Serial : 0000000000000000 Operating system info: cat /etc/openwrt_release DISTRIB_ID='OpenWrt' DISTRIB_RELEASE='15.05' DISTRIB_REVISION='r48153' DISTRIB_CODENAME='chaos_calmer' DISTRIB_TARGET='imx6/generic' DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05' DISTRIB_TAINTS='no-all busybox' cat /proc/version Linux version 3.18.23 (gcc version 5.3.0 (OpenWrt GCC 5.3.0 r48153) ) #6 SMP Tue Jul 11 16:35:20 CEST 2017 Source code could be downloaded from: https://uclibc.org/downloads/uClibc-0.9.33.2.tar.bz2 Extracted chunks from trace output can be downloaded from: https://github.com/KKoovalsky/Valgrind-problems The file is called vgtrace-shortened.txt. Full trace available in vgtrace.txt file. In this repo I also included compiled uClibc library. I am wondering if GCC update could have caused such behavior. I've been running image compiled with GCC-4.8-Linaro, then I bumped the GCC package version to use GCC-5.3, run firmware update and then installed valgrind and other software which was compiled with buildroot which uses GCC-5.3. I will try to check if this problem is reproducible by flashing from image which was initially compiled with GCC-5.3. 2017-09-05 18:35 GMT+02:00 John Reiser <jr...@bi...>: > > 1. > > ==4996== Invalid read of size 4 > > ==4996== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so < > http://ld-uClibc-0.9.33.2.so>) > > ==4996== Address 0x7dbb6664 is on thread 1's stack > > ==4996== 20 bytes below stack pointer > >> GDB: >> >> 1. >> (gdb) info reg >> r0 0x4007148 67137864 >> r1 0x0 0 >> r2 0x49ba000 77307904 >> r3 0x49bd90c 77322508 >> r4 0x4015f78 67198840 >> r5 0x4006054 67133524 >> r6 0xa 10 >> r7 0x4006ac0 67136192 >> r8 0x24 36 >> r9 0x401602c 67199020 >> r10 0x7dbb6a48 2109434440 >> r11 0x7dbb6674 2109433460 >> r12 0x7dbb6678 2109433464 >> sp 0x7dbb6678 0x7dbb6678 >> lr 0x40054ec 67130604 >> pc 0x40054ec 0x40054ec >> cpsr 0x20000010 536870928 >> (gdb) x/9i $pc-4*4 >> 0x40054dc: beq 0x40054ec >> 0x40054e0: ldr r2, [r7] >> 0x40054e4: add r3, r3, r2 >> 0x40054e8: blx r3 >> => 0x40054ec: mov r0, r7 >> 0x40054f0: bl 0x4001440 >> 0x40054f4: b 0x40054b8 >> 0x40054f8: ldr r1, [r6, #88] ; 0x58 >> 0x40054fc: sub sp, sp, #16 >> >> > This is strange. None of the instructions (in any of the four cases) > that are designated by the address in "at 0x..." is a memory fetch 'ldr' > which would be necessary to correspond to the complaint "Invalid read of > size 4". > > However, I see that each of the 4 complaints is immediately after a 'blx' > instruction. > 'blx' has a history of problems in both hardware and software. > Exactly what hardware are you running? Please report the output of > "lscpu" and "cat /proc/cpuinfo". > Also, please tell us which Linux distribution, and the exact package name > of the > compiled binary package for uClibc, and where anyone can download a copy > of the package > (both compiled binary and source code). > > Meanwhile, please invoke with these diagnostic flags: > valgrind --trace-notbelow=0 --trace-flags=10000000 /bin/true > 2>vgtrace.txt > > The re-directed stderr vgtrace.txt will be an instruction-by-instruction > trace > [it will be large, probably about 5 MB or so] where the individual blocks > look like > ***** [This example was generated on x86_64.] > ==== SB 0 (evchecks 0) [tid 1] 0x4000c50 UNKNOWN_FUNCTION /usr/lib64/ > ld-2.24.so+0xc50 > > ------------------------ Front end ------------------------ > > 0x4000C50: movq %rsp,%rdi > > ------ IMark(0x4000C50, 3, 0) ------ > PUT(72) = GET:I64(48) > PUT(184) = 0x4000C53:I64 > ***** > where the "SB 0" is a serial number of the block. Find the 'blx' > instruction > and its enclosing "SB nnnnn". Then look forward until you find the SB for > the > pc that is specified in the complaint from memcheck. Select the entire > range of SB > (from the 'blx' to the complaint) into a file, gzip it, and upload it > somewhere > that anyone interested can download it. The idea is to find out how > memcheck > got the address that it is complaining about. > > > -- > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |