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 <jrei...@bitwagon.com>:
> > 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
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
------------------------------------------------------------------------------
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
