Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
|
|
From: John R. <jr...@bi...> - 2017-09-06 18:20:25
|
> memcheck's bug is reporting the location "at 0x..." using the new value that was loaded into pc, > instead of the original value of the pc of the instruction which suffered the complaint. https://bugs.kde.org/show_bug.cgi?id=384442 "ARM: bad pc in complaint if instruction changes pc" -- |
|
From: John R. <jr...@bi...> - 2017-09-06 17:33:13
|
> cat /proc/cpuinfo [[snip]] > 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. Thank you for the detailed information, particularly the vgtrace*.txt. It's a compiler "bug", and a "bug" in the memcheck implementation, and a definite bug in the memcheck error reporting. The workaround is to invoke valgrind(memcheck) with "--ignore-range-below-sp=0x0-0x14". The problem can be seen here: ===== vgtrace-shortened.txt line 8308 (arm) 0x4817678: mov r12, r13 ## copy r12 from r13(==sp) ------ IMark(0x4817678, 4, 0) ------ t1 = GET:I32(60) t0 = t1 t2 = t0 PUT(56) = t2 PUT(68) = 0x481767C:I32 (arm) 0x481767C: stmdb r13!, {0xDFF0} ## push r15(==pc),r14(==lr),r12,r11-r4 onto stack (sp===r13) *in that order* ------ IMark(0x481767C, 4, 0) ------ t3 = GET:I32(60) t4 = t3 PUT(60) = Sub32(t3,0x2C:I32) STle(Sub32(t4,0x4:I32)) = 0x4817684:I32 STle(Sub32(t4,0x8:I32)) = GET:I32(64) STle(Sub32(t4,0xC:I32)) = GET:I32(56) STle(Sub32(t4,0x10:I32)) = GET:I32(52) STle(Sub32(t4,0x14:I32)) = GET:I32(48) STle(Sub32(t4,0x18:I32)) = GET:I32(44) STle(Sub32(t4,0x1C:I32)) = GET:I32(40) STle(Sub32(t4,0x20:I32)) = GET:I32(36) STle(Sub32(t4,0x24:I32)) = GET:I32(32) STle(Sub32(t4,0x28:I32)) = GET:I32(28) STle(Sub32(t4,0x2C:I32)) = GET:I32(24) PUT(68) = 0x4817680:I32 (arm) 0x4817680: sub r11, r12, #0x4 ## r12 has same value as sp before the 'stmdb' ------ IMark(0x4817680, 4, 0) ------ t5 = GET:I32(56) t6 = 0x4:I32 t7 = Sub32(t5,t6) PUT(52) = t7 PUT(68) = 0x4817684:I32 (arm) 0x4817684: ldmdb r11, {0xAFF0} ## load r15(==pc) from stored lr, r13(==sp) from stored r12, r11-r4 from stored original values ------ IMark(0x4817684, 4, 0) ------ t8 = GET:I32(52) t9 = t8 PUT(68) = LDle:I32(Sub32(t9,0x4:I32)) PUT(60) = LDle:I32(Sub32(t9,0x8:I32)) PUT(48) = LDle:I32(Sub32(t9,0x10:I32)) PUT(44) = LDle:I32(Sub32(t9,0x14:I32)) PUT(40) = LDle:I32(Sub32(t9,0x18:I32)) PUT(36) = LDle:I32(Sub32(t9,0x1C:I32)) PUT(32) = LDle:I32(Sub32(t9,0x20:I32)) PUT(28) = LDle:I32(Sub32(t9,0x24:I32)) PUT(24) = LDle:I32(Sub32(t9,0x28:I32)) PUT(52) = LDle:I32(Sub32(t9,0xC:I32)) PUT(68) = GET:I32(68) PUT(68) = GET:I32(68); exit-Boring GuestBytes 4817678 16 0D C0 A0 E1 F0 DF 2D E9 04 B0 4C E2 F0 AF 1B E9 0028F343 VexExpansionRatio 16 952 595 :10 ==26904== Invalid read of size 4 ==26904== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so) ==26904== Address 0x7dad09fc is on thread 1's stack ==26904== 20 bytes below stack pointer ===== The net effect of those 3 instructions is: r0-r3 do not change; none of them was written r4-r10 do not change; each value is stored and fetched to/from the same (corresponding) address r11 = (r12 - 4) from the 'sub' r12 gets the original (and final) value of r13(==sp) r13(==sp) does not change. It was decremented by 44 (11 registers times 4 bytes per register) but then loaded from the location which was written with the value of r12, which is the same as the original sp r14(==lr) does not change; it never was written r15(==pc) is loaded from the original value in r14(==lr) which is the return address memcheck's bug is reporting the location "at 0x..." using the new value that was loaded into pc, instead of the original value of the pc of the instruction which suffered the complaint. The compiler bug is relying on a particular implementation of poorly-specified hardware. The "ldmdb r11, {0xAFF0}" reads 10 words from memory, and changes the value of r13(==sp) among other registers. The compiler assumes that the change to r13 does not become visible until the entire instruction has completed, yet this is not guaranteed explicitly. It is conceivable that the 'ldmdb' could be interrupted immediately after writing r13(==sp), save internal state as part of servicing the interrupt, and resume state upon return. If so, then the fetches to load the remaining registers are outside the boundary of the stack (namely, less than the downward-growing sp), and that's a memcheck error. On the other hand, all known hardware does not allow such an interrupt (all side effects are "atomic") so the memcheck implementation is not faithful because it uses the new value of r13(==sp) to check subsequent memory fetches for other registers before the 'lmdb' instruction ends. The compiler's choice of storing and re-loading r4-r11 is horribly inefficient: 8 writes and 8 reads that only waste time. The value stored from r15(==pc) via the 'stmdb' never is read. The entire sequence could be replaced by "bx lr" or "mov pc,lr", (possibly preceded by "mov r12,sp"); except that 'bx' is not implemented in some early hardware, and "mov pc,lr" is frowned upon in hardware that does have 'bx'. One possible solution that works everywhere is to use "blx lr" and just ignore the value that is written to lr. -- |
|
From: Kacper K. <kac...@gm...> - 2017-09-06 15:42:53
|
I booted from new image which was compiled fully with GCC-5.3 and the
problem still occurs. The advantage is that packages with debug symbols
were used and I can use the bt gdb command.
GDB:
(gdb) set verbose on
(gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=8269
Remote debugging using | /usr/lib/valgrind/../../bin/vgdb --pid=8269
relaying data between gdb and process 8269
Reading symbols from /lib/ld-uClibc.so.0...done.
Loaded symbols for /lib/ld-uClibc.so.0
0x04000e68 in _start () from /lib/ld-uClibc.so.0
(gdb) c
Continuing.
Reading in symbols for ldso/ldso/ldso.c...done.
Reading symbols from /usr/lib/valgrind/vgpreload_core-arm-linux.so...done.
Loaded symbols for /usr/lib/valgrind/vgpreload_core-arm-linux.so
Reading symbols from
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so...done.
Loaded symbols for /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
Reading symbols from /usr/lib/libboost_thread.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_thread.so.1.64.0
Reading symbols from /usr/lib/libboost_system.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_system.so.1.64.0
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.0...done.
Loaded symbols for /lib/libm.so.0
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.0...done.
Loaded symbols for /lib/libc.so.0
Reading symbols from /usr/lib/libboost_atomic.so.1.64.0...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/libboost_atomic.so.1.64.0
Reading symbols from /lib/librt.so.0...done.
Loaded symbols for /lib/librt.so.0
Reading symbols from /lib/libdl.so.0...done.
Loaded symbols for /lib/libdl.so.0
Program received signal SIGTRAP, Trace/breakpoint trap.
_dl_get_ready_to_run (Reading in symbols for
libc/sysdeps/linux/arm/crti.S...done.
tpnt=0x4007ac0, load_addr=<optimized out>, auxvt=0x7d80ca48,
envp=<optimized out>, argv=0x0) at ldso/ldso/ldso.c:1396
1396 ldso/ldso/ldso.c: No such file or directory.
Current language: auto
The current source language is "auto; currently c".
(gdb) bt
#0 _dl_get_ready_to_run (tpnt=0x4007ac0, load_addr=<optimized out>,
auxvt=0x7d80ca48, envp=<optimized out>, argv=0x0) at ldso/ldso/ldso.c:1396
#1 0x049be918 in _init () at libc/sysdeps/linux/arm/crti.S:22
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
Reading in symbols for libc/misc/internals/__uClibc_main.c...done.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x04a170a0 in __uClibc_main (main=0x7d80cc04, argc=77770752, argv=Reading
in symbols for libc/sysdeps/linux/arm/crtn.S...done.
0x104e4 <_init+12>, app_init=Reading in symbols for
libc/sysdeps/linux/arm/crti.S...done.
0x104d8 <_init>, app_fini=0x10680 <_fini>, rtld_fini=0x4000df0 <_dl_fini>,
stack_end=0x7d80cc04) at libc/misc/internals/__uClibc_main.c:440
440 libc/misc/internals/__uClibc_main.c: No such file or directory.
(gdb) bt
#0 0x04a170a0 in __uClibc_main (main=0x7d80cc04, argc=77770752,
argv=0x104e4 <_init+12>, app_init=0x104d8 <_init>, app_fini=0x10680
<_fini>,
rtld_fini=0x4000df0 <_dl_fini>, stack_end=0x7d80cc04) at
libc/misc/internals/__uClibc_main.c:440
#1 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
__GI___uClibc_fini () at libc/misc/internals/__uClibc_main.c:304
304 in libc/misc/internals/__uClibc_main.c
(gdb) bt
Reading in symbols for libc/stdlib/exit.c...done.
#0 __GI___uClibc_fini () at libc/misc/internals/__uClibc_main.c:304
#1 0x04a134bc in __GI_exit (rv=0) at libc/stdlib/_atexit.c:336
#2 0x04a17190 in __uClibc_main (main=0x7d80cc04, argc=77770752,
argv=0x4a17190 <__uClibc_main+764>, app_init=0x0, app_fini=0x10680 <_fini>,
rtld_fini=0x4000df0 <_dl_fini>, stack_end=0x7d80cc04) at
libc/misc/internals/__uClibc_main.c:511
#3 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
_dl_fini () at ldso/ldso/ldso.c:311
311 ldso/ldso/ldso.c: No such file or directory.
(gdb) bt
Reading in symbols for libc/sysdeps/linux/arm/crti.S...done.
#0 _dl_fini () at ldso/ldso/ldso.c:311
#1 0x04818684 in _fini () at libc/sysdeps/linux/arm/crti.S:41
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
[Inferior 1 (Remote target) exited normally]
GDBSERVER:
==8269== Memcheck, a memory error detector
==8269== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==8269== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==8269== Command: /nmi/programs/inter_empty/bin/inter_empty
==8269==
==8269== (action at startup) vgdb me ...
==8269==
==8269== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==8269== /path/to/gdb /nmi/programs/inter_empty/bin/inter_empty
==8269== and then give GDB the following command
==8269== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=8269
==8269== --pid is optional if only one valgrind process is running
==8269==
==8269== Invalid read of size 4
==8269== at 0x40058F8: _dl_get_ready_to_run (ldso.c:1396)
==8269== Address 0x7d80c624 is on thread 1's stack
==8269== 20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269== at 0x4A170A0: __uClibc_main (__uClibc_main.c:440)
==8269== by 0xFFFFFFFF: ???
==8269== Address 0x7d80ca34 is on thread 1's stack
==8269== 20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269== at 0x4A16E70: __uClibc_fini (__uClibc_main.c:304)
==8269== by 0x4A134BB: exit (_atexit.c:336)
==8269== by 0x4A1718F: __uClibc_main (__uClibc_main.c:511)
==8269== by 0xFFFFFFFF: ???
==8269== Address 0x7d80ca0c is on thread 1's stack
==8269== 20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269== Invalid read of size 4
==8269== at 0x4000E54: ??? (ldso.c:311)
==8269== Address 0x7d80c9fc is on thread 1's stack
==8269== 20 bytes below stack pointer
==8269==
==8269== (action on error) vgdb me ...
==8269== Continuing ...
==8269==
==8269== HEAP SUMMARY:
==8269== in use at exit: 20,224 bytes in 1 blocks
==8269== total heap usage: 6 allocs, 5 frees, 20,632 bytes allocated
==8269==
==8269== LEAK SUMMARY:
==8269== definitely lost: 0 bytes in 0 blocks
==8269== indirectly lost: 0 bytes in 0 blocks
==8269== possibly lost: 0 bytes in 0 blocks
==8269== still reachable: 20,224 bytes in 1 blocks
==8269== suppressed: 0 bytes in 0 blocks
==8269== Rerun with --leak-check=full to see details of leaked memory
==8269==
==8269== For counts of detected and suppressed errors, rerun with: -v
==8269== ERROR SUMMARY: 128 errors from 4 contexts (suppressed: 0 from 0)
|
|
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 > |
|
From: John R. <jr...@bi...> - 2017-09-05 16:36:00
|
> 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. -- |
|
From: Kacper K. <kac...@gm...> - 2017-09-05 09:09:33
|
Ok. Sorry, I overlooked it
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
2.
(gdb) info reg
r0 0x7dbb6d21 2109435169
r1 0x4a2b000 77770752
r2 0x10680 67200
r3 0x4a2f494 77788308
r4 0x7dbb6d03 2109435139
r5 0x104d8 66776
r6 0x7dbb6a60 2109434464
r7 0x8 8
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a4c 2109434444
r12 0x7dbb6a50 2109434448
sp 0x7dbb6a50 0x7dbb6a50
lr 0x4a15cd4 77683924
pc 0x4a15cd4 0x4a15cd4
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4a15cc4: add r3, pc, r3
0x4a15cc8: str r2, [r3]
0x4a15ccc: beq 0x4a15cd4
0x4a15cd0: blx r5
=> 0x4a15cd4: bl 0x49ddf00
0x4a15cd8: ldr r3, [pc, #288] ; 0x4a15e00
0x4a15cdc: ldr r2, [sp]
0x4a15ce0: ldr r3, [r2, r3]
0x4a15ce4: cmp r3, #0
3.
(gdb) info reg
r0 0x207d8 133080
r1 0x1 1
r2 0x0 0
r3 0x10680 67200
r4 0x4a2b000 77770752
r5 0x0 0
r6 0x7dbb6a60 2109434464
r7 0x4a2b400 77771776
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a2c 2109434412
r12 0x7dbb6a30 2109434416
sp 0x7dbb6a30 0x7dbb6a30
lr 0x4a15ac0 77683392
pc 0x4a15ac0 0x4a15ac0
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4a15ab0: ldr r3, [r3]
0x4a15ab4: cmp r3, #0
0x4a15ab8: beq 0x4a15ac0
0x4a15abc: blx r3
=> 0x4a15ac0: ldr r3, [pc, #24] ; 0x4a15ae0
0x4a15ac4: add r3, pc, r3
0x4a15ac8: ldr r3, [r3]
0x4a15acc: cmp r3, #0
0x4a15ad0: popeq {r4, pc}
4.
(gdb) info reg
r0 0x482778c 75659148
r1 0x1 1
r2 0x4817000 75591680
r3 0x4817678 75593336
r4 0x4006178 67133816
r5 0x0 0
r6 0x4016034 67199028
r7 0x401602c 67199020
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7dbb6a1c 2109434396
r12 0x7dbb6a20 2109434400
sp 0x7dbb6a20 0x7dbb6a20
lr 0x4000e54 67112532
pc 0x4000e54 0x4000e54
cpsr 0x20000010 536870928
(gdb) x/9i $pc-4*4
0x4000e44: beq 0x4000e54
0x4000e48: ldr r2, [r4]
0x4000e4c: add r3, r3, r2
0x4000e50: blx r3
=> 0x4000e54: add r5, r5, #1
0x4000e58: b 0x4000e0c
0x4000e5c: pop {r4, r5, r6, r7, r11, pc}
0x4000e60: andeq r5, r1, r8, lsr #4
0x4000e64: andeq r5, r1, r12, lsl r2
Corresponding GDB server messages:
1.
==4996== Invalid read of size 4
==4996== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==4996== Address 0x7dbb6664 is on thread 1's stack
==4996== 20 bytes below stack pointer
2.
==4996== Invalid read of size 4
==4996== at 0x4A15CD4: ??? (in /lib/libuClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a3c is on thread 1's stack
==4996== 20 bytes below stack pointer
3.
==4996== Invalid read of size 4
==4996== at 0x4A15AC0: ??? (in /lib/libuClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a1c is on thread 1's stack
==4996== 20 bytes below stack pointer
4.
==4996== Invalid read of size 4
==4996== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==4996== Address 0x7dbb6a0c is on thread 1's stack
==4996== 20 bytes below stack pointer
uname -a:
Linux XXX 3.18.23 #6 SMP Tue Jul 11 16:35:20 CEST 2017 armv7l GNU/Linux
readelf --segments /bin/true | grep interpreter:
[Requesting program interpreter: /lib/ld-uClibc.so.0]
Changing uClibc package to compile with debugging symbols can result in
rebuilding whole buildroot and reflashing my embedded device. It could last
a few days, so I think that it will be last step I will take if any of
solutions won't work.
2017-09-02 14:14 GMT+02:00 John Reiser <jr...@bi...>:
> From valgrind(memcheck):
>
>> ==2418== Invalid read of size 4
>> ==2418== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
>> ==2418== Address 0x7d87a664 is on thread 1's stack
>> ==2418== 20 bytes below stack pointer
>>
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x040054ec in ?? ()
>>
>
> From the vgdb server:
>
>> (gdb) info reg
>>
>
> r10 0x7d87aa48 2106042952
>> r11 0x7d87a674 2106041972
>> r12 0x7d87a678 2106041976
>> sp 0x7d87a678 0x7d87a678
>>
>
> pc 0x40054ec 0x40054ec
>>
>
> So the description "20 bytes below stack pointer" is correct,
> because ($sp - 0x7d87a664) = (0x7d87a678 - 0x7d87a664) = 0x14 = 20.
>
> What was the instruction stream? Where is the output from
> the next command that was requested in my earlier message:
> (gdb) x/9i $pc-4*4
>
> If the instruction at 0x040054ec is a 'ldr' fetch from memory
> which uses address -996(r10), -16(r11), -20(r12), or -20(sp),
> then that is the culprit, and it is a compiler error (or a logic
> error if indexing an array with an index less than zero,
> or a programmer error if the code was inlined assembly language.)
>
> Also, were you able to install the debuginfo symbols for /lib/
> ld-uClibc-0.9.33.2.so ?
> (or, not strip the symbols from ld-uClibc ?)
> It would be nice to correlate the instruction stream with the source code:
> (gdb) bt
> which should show function names, source file names, and line numbers.
> This would make it easier to confirm the exact cause of the error.
>
>
> --
>
> ------------------------------------------------------------
> ------------------
> 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
>
|
|
From: Ivo R. <iv...@iv...> - 2017-09-04 06:29:53
|
Dear developers, Would the Valgrind community be interested in a Valgrind developer room at FOSDEM 2018 [1]? The deadline for developer room proposals is September 20th. I volunteer to help with the organization, similarly to the last year. We had a dev room at FOSDEM 2014, 2015, and 2017 and it seemed to be quite interesting experience for all participating... If I remember correctly, devroom at FOSDEM 2017 was constantly over packed! Kind regards, I. [1] https://submission.fosdem.org/devroom.php |
|
From: John R. <jr...@bi...> - 2017-09-02 12:14:54
|
From valgrind(memcheck): > ==2418== Invalid read of size 4 > ==2418== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so) > ==2418== Address 0x7d87a664 is on thread 1's stack > ==2418== 20 bytes below stack pointer > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x040054ec in ?? () From the vgdb server: > (gdb) info reg > r10 0x7d87aa48 2106042952 > r11 0x7d87a674 2106041972 > r12 0x7d87a678 2106041976 > sp 0x7d87a678 0x7d87a678 > pc 0x40054ec 0x40054ec So the description "20 bytes below stack pointer" is correct, because ($sp - 0x7d87a664) = (0x7d87a678 - 0x7d87a664) = 0x14 = 20. What was the instruction stream? Where is the output from the next command that was requested in my earlier message: (gdb) x/9i $pc-4*4 If the instruction at 0x040054ec is a 'ldr' fetch from memory which uses address -996(r10), -16(r11), -20(r12), or -20(sp), then that is the culprit, and it is a compiler error (or a logic error if indexing an array with an index less than zero, or a programmer error if the code was inlined assembly language.) Also, were you able to install the debuginfo symbols for /lib/ld-uClibc-0.9.33.2.so ? (or, not strip the symbols from ld-uClibc ?) It would be nice to correlate the instruction stream with the source code: (gdb) bt which should show function names, source file names, and line numbers. This would make it easier to confirm the exact cause of the error. -- |
|
From: Kacper K. <kac...@gm...> - 2017-09-01 10:00:11
|
John Reiser
17:27 (18 godzin temu)
> ==19124== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so <
http://ld-uClib...
Kacper Kowalski <kac...@gm...>
11:57 (1 minutę temu)
do John
Hi!
By default valgrind is not selectable in menuconfig for IMX6 platform when
cross compiling for Openwrt, but this platform is based on ARM Cortex A9
core which is implementing ARMv7 architecture. This architecture is
supported by valgrind, so I made little changes in Makefile of valgrind
package to make the package selectable from menuconfig and compilable.
I'm using GCC-5.3 and uClibc-0.9.33.2 (can't proceed to musl for now
because it is very expensive).
The problem is that valgrind is not working properly even for /bin/true:
> valgrind --leak-check=yes /bin/true
Output:
==19124== Memcheck, a memory error detector
==19124== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19124== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==19124== Command: /bin/true
==19124==
==19124== Invalid read of size 4
==19124== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==19124== Address 0x7df01864 is on thread 1's stack
==19124== 20 bytes below stack pointer
==19124==
==19124== Invalid read of size 4
==19124== at 0x48B8CD4: ??? (in /lib/libuClibc-0.9.33.2.so)
==19124== Address 0x7df01a5c is on thread 1's stack
==19124== 20 bytes below stack pointer
==19124==
==19124== Invalid read of size 4
==19124== at 0x48B8AC0: ??? (in /lib/libuClibc-0.9.33.2.so)
==19124== Address 0x7df01a04 is on thread 1's stack
==19124== 20 bytes below stack pointer
==19124==
==19124== Invalid read of size 4
==19124== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==19124== Address 0x7df019f4 is on thread 1's stack
==19124== 20 bytes below stack pointer
==19124==
==19124==
==19124== HEAP SUMMARY:
==19124== in use at exit: 0 bytes in 0 blocks
==19124== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==19124==
==19124== All heap blocks were freed -- no leaks are possible
==19124==
==19124== For counts of detected and suppressed errors, rerun with: -v
==19124== ERROR SUMMARY: 64 errors from 4 contexts (suppressed: 0 from 0)
I found that "-D__UCLIBC__" flag should be applied when compiling valgrind,
but that didn't help, the output is the same.
Thank you for the answer.
I thought that the complaint is incorrect because it's complaining on a
simple program. Now I know that the complaint could be correct.
I couldn't run /bin/true in way you recommended, because no debug
information was provided, so I compiled simplest program with debug switch:
#include <iostream>
int main()
{
return 0;
}
Started gdbserver and connected to it using command:
(gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=2418
The output from gdb till first error:
Remote debugging using | /usr/lib/valgrind/../../bin/vgdb --pid=2418
relaying data between gdb and process 2418
Reading symbols from /lib/ld-uClibc.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-uClibc.so.0
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Cannot access memory at address 0x0
0x04000e68 in ?? ()
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x040054ec in ?? ()
(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 0x7d87aa48 2106042952 <%28210%29%20604-2952>
r11 0x7d87a674 2106041972 <%28210%29%20604-1972>
r12 0x7d87a678 2106041976 <%28210%29%20604-1976>
sp 0x7d87a678 0x7d87a678
lr 0x40054ec 67130604
pc 0x40054ec 0x40054ec
cpsr 0x20000010 536870928
Corresponding output from gdbserver:
==2418== Invalid read of size 4
==2418== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==2418== Address 0x7d87a664 is on thread 1's stack
==2418== 20 bytes below stack pointer
==2418==
==2418== (action on error) vgdb me ...
Next error:
(gdb) info reg
r0 0x7d87ad21 2106043681 <%28210%29%20604-3681>
r1 0x4a2b000 77770752
r2 0x10680 67200
r3 0x4a2f494 77788308
r4 0x7d87ad03 2106043651 <%28210%29%20604-3651>
r5 0x104d8 66776
r6 0x7d87aa60 2106042976 <%28210%29%20604-2976>
r7 0x8 8
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7d87aa4c 2106042956 <%28210%29%20604-2956>
r12 0x7d87aa50 2106042960 <%28210%29%20604-2960>
sp 0x7d87aa50 0x7d87aa50
lr 0x4a15cd4 77683924
pc 0x4a15cd4 0x4a15cd4
cpsr 0x20000010 536870928
And corresponding gdbserver output:
==2418== Invalid read of size 4
==2418== at 0x4A15CD4: ??? (in /lib/libuClibc-0.9.33.2.so)
==2418== Address 0x7d87aa3c is on thread 1's stack
==2418== 20 bytes below stack pointer
Next error:
(gdb) info reg
r0 0x207d8 133080
r1 0x1 1
r2 0x0 0
r3 0x10680 67200
r4 0x4a2b000 77770752
r5 0x0 0
r6 0x7d87aa60 2106042976 <%28210%29%20604-2976>
r7 0x4a2b400 77771776
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7d87aa2c 2106042924 <%28210%29%20604-2924>
r12 0x7d87aa30 2106042928 <%28210%29%20604-2928>
sp 0x7d87aa30 0x7d87aa30
lr 0x4a15ac0 77683392
pc 0x4a15ac0 0x4a15ac0
cpsr 0x20000010 536870928
Gdbserver:
==2418== Invalid read of size 4
==2418== at 0x4A15AC0: ??? (in /lib/libuClibc-0.9.33.2.so)
==2418== Address 0x7d87aa1c is on thread 1's stack
==2418== 20 bytes below stack pointer
And the last one:
(gdb) info reg
r0 0x482778c 75659148
r1 0x1 1
r2 0x4817000 75591680
r3 0x4817678 75593336
r4 0x4006178 67133816
r5 0x0 0
r6 0x4016034 67199028
r7 0x401602c 67199020
r8 0x0 0
r9 0x0 0
r10 0x4015f78 67198840
r11 0x7d87aa1c 2106042908 <%28210%29%20604-2908>
r12 0x7d87aa20 2106042912 <%28210%29%20604-2912>
sp 0x7d87aa20 0x7d87aa20
lr 0x4000e54 67112532
pc 0x4000e54 0x4000e54
cpsr 0x20000010 536870928
Gdbserver:
==2418== Invalid read of size 4
==2418== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so)
==2418== Address 0x7d87aa0c is on thread 1's stack
==2418== 20 bytes below stack pointer
Summary:
==2418== HEAP SUMMARY:
==2418== in use at exit: 0 bytes in 0 blocks
==2418== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2418==
==2418== All heap blocks were freed -- no leaks are possible
==2418==
==2418== For counts of detected and suppressed errors, rerun with: -v
==2418== ERROR SUMMARY: 128 errors from 4 contexts (suppressed: 0 from 0)
|
|
From: John R. <jr...@bi...> - 2017-08-31 15:28:09
|
> By default valgrind is not selectable in menuconfig for IMX6 platform when cross compiling for Openwrt, but this platform is based on ARM Cortex A9 core which is implementing ARMv7 architecture. This architecture is supported by valgrind, so I made little changes in Makefile of valgrind package to > make the package selectable from menuconfig and compilable. > I'm using GCC-5.3 and uClibc-0.9.33.2 (can't proceed to musl for now because it is very expensive). > The problem is that valgrind is not working properly even for |/bin/true|: > > | > valgrind --leak-check=yes /bin/true | > > |Output: > | > ==19124== Memcheck, a memory error detector > ==19124== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==19124== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info > ==19124== Command: /bin/true > ==19124== > ==19124== Invalid read of size 4 > ==19124== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so <http://ld-uClibc-0.9.33.2.so>) > ==19124== Address 0x7df01864 is on thread 1's stack > ==19124== 20 bytes below stack pointer How do you know that memcheck's complaint is incorrect? At times in the past messages such as these were valid complaints, particularly for uClibc and some compilers for ARM and MIPS. Find some way to look at register values and instruction stream in the context of the error. If the valgrind gdb server is installed and working, then one good way is to invoke via valgrind --vgdb-error=0 /bin/true and follow the directions. (gdb) continue ## to get started Then at the point of complaint by memcheck: (gdb) info reg ## values of all registers (gdb) x/9i $pc-4*4 ## probable instruction stream It would also help to install the debuginfo package for uClibc (compiled with -g) so that you could get a meaningful backtrace via the "bt" command to gdb, but that might be a lot of work. Please tell us the target operating system version ("uname -a"), and which ELF program INTERP (readelf --segments /bin/true | grep interpreter). -- |
|
From: Kacper K. <kac...@gm...> - 2017-08-31 14:19:32
|
Hi! By default valgrind is not selectable in menuconfig for IMX6 platform when cross compiling for Openwrt, but this platform is based on ARM Cortex A9 core which is implementing ARMv7 architecture. This architecture is supported by valgrind, so I made little changes in Makefile of valgrind package to make the package selectable from menuconfig and compilable. I'm using GCC-5.3 and uClibc-0.9.33.2 (can't proceed to musl for now because it is very expensive). The problem is that valgrind is not working properly even for /bin/true: > valgrind --leak-check=yes /bin/true Output: ==19124== Memcheck, a memory error detector ==19124== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==19124== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==19124== Command: /bin/true ==19124== ==19124== Invalid read of size 4 ==19124== at 0x40054EC: ??? (in /lib/ld-uClibc-0.9.33.2.so) ==19124== Address 0x7df01864 is on thread 1's stack ==19124== 20 bytes below stack pointer ==19124== ==19124== Invalid read of size 4 ==19124== at 0x48B8CD4: ??? (in /lib/libuClibc-0.9.33.2.so) ==19124== Address 0x7df01a5c is on thread 1's stack ==19124== 20 bytes below stack pointer ==19124== ==19124== Invalid read of size 4 ==19124== at 0x48B8AC0: ??? (in /lib/libuClibc-0.9.33.2.so) ==19124== Address 0x7df01a04 is on thread 1's stack ==19124== 20 bytes below stack pointer ==19124== ==19124== Invalid read of size 4 ==19124== at 0x4000E54: ??? (in /lib/ld-uClibc-0.9.33.2.so) ==19124== Address 0x7df019f4 is on thread 1's stack ==19124== 20 bytes below stack pointer ==19124== ==19124== ==19124== HEAP SUMMARY: ==19124== in use at exit: 0 bytes in 0 blocks ==19124== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==19124== ==19124== All heap blocks were freed -- no leaks are possible ==19124== ==19124== For counts of detected and suppressed errors, rerun with: -v ==19124== ERROR SUMMARY: 64 errors from 4 contexts (suppressed: 0 from 0) I found that "-D__UCLIBC__" flag should be applied when compiling valgrind, but that didn't help, the output is the same. |
|
From: Philippe W. <phi...@sk...> - 2017-08-30 19:13:11
|
On Wed, 2017-08-30 at 11:16 +0200, Dominik Straßer wrote:
> As there are many different BN_* functions causing these errors I would
> like to use a global suppression. I tried:
> {
> crypto2
> Memcheck:Cond
> obj: */libcrypto.so.1.0.0
> }
> and
> {
> crypto2
> Memcheck:Cond
> ...
> obj: */libPocoCrypto64.so.*
> }
> and many variations of these. Only individual ones like
> {
> bn
> Memcheck:Cond
> fun:BN_bin2bn
> }
> do work.
>
> Any hints from your side ?
Try a variant without space after obj:
As far as I can see, the manual for suppression does not describe any
character being special apart of * and ?.
And the suppression parsing code just skips 4 characters when it
recognises obj:
So, space is not special, and the matching logic will try to find
<space>*/libcrypto.so.1.0.0
or similar.
Philippe
|
|
From: Tom H. <to...@co...> - 2017-08-30 19:08:42
|
Suppression can't really help with this - even if you can stop one or two complaints the undefined bits tend to propagate through the encryption state and hence to everything encrypted or decrypted using the state that is (partially) derived from the undefined data. Tom On 30/08/17 16:51, Dominik Straßer wrote: > Hi Julian, > similar to my answer to John: > why isn't suppression working here ? > > Regards > > Dominik > > Am 30.08.2017 um 17:32 schrieb Julian Seward: >>> As these seem OK to me (cryprography intentionally works with >>> uninitialized values) I would like to suppress them. >> Another thing you could consider doing, if you really have to use undefined >> values, is to figure out where they come from (heap or stack allocation, >> use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is >> called) client request. This lies to Memcheck, claiming the inputs are >> defined when they are not really. But at least it will not complain about >> undefinedness from them alone, after that. >> >> See <valgrind/memcheck.h>. >> >> J > > > ------------------------------------------------------------------------------ > 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 > -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Dominik S. <dom...@on...> - 2017-08-30 18:25:08
|
Hi Julian, similar to my answer to John: why isn't suppression working here ? Regards Dominik Am 30.08.2017 um 17:32 schrieb Julian Seward: >> As these seem OK to me (cryprography intentionally works with >> uninitialized values) I would like to suppress them. > Another thing you could consider doing, if you really have to use undefined > values, is to figure out where they come from (heap or stack allocation, > use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is > called) client request. This lies to Memcheck, claiming the inputs are > defined when they are not really. But at least it will not complain about > undefinedness from them alone, after that. > > See <valgrind/memcheck.h>. > > J |
|
From: Julian S. <js...@ac...> - 2017-08-30 15:32:55
|
> As these seem OK to me (cryprography intentionally works with > uninitialized values) I would like to suppress them. Another thing you could consider doing, if you really have to use undefined values, is to figure out where they come from (heap or stack allocation, use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is called) client request. This lies to Memcheck, claiming the inputs are defined when they are not really. But at least it will not complain about undefinedness from them alone, after that. See <valgrind/memcheck.h>. J |
|
From: John R. <jr...@bi...> - 2017-08-30 13:11:25
|
> I have a lot of memcheck errors from libcrypto. This is a FAQ! Search the net. libcrypto deliberately uses uninit values as an additional source of randomness. If you want to run memcheck on a program that uses libcrypto, then you should get the source code for libcrypto and build it with a particular #define which turns off those deliberate uninit values. This is well-documented in the source for libcrypto. -- |
|
From: Dominik S. <dom...@on...> - 2017-08-30 11:51:37
|
Hi,
I have a lot of memcheck errors from libcrypto.
As these seem OK to me (cryprography intentionally works with
uninitialized values) I would like to suppress them.
The errors look like this:
==45293== Conditional jump or move depends on uninitialised value(s)
==45293== at 0x8BEF2F9: BN_bin2bn (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF357B: BN_rand (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF3159: bn_rand_range (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF46A0: BN_BLINDING_create_param (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C27294: RSA_setup_blinding (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C1DE46: rsa_get_blinding (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C1EE5F: RSA_eay_private_decrypt (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x91D5FA2: ??? (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D3C88: Poco::Crypto::CryptoStreamBuf::close() (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D16B1: Poco::Crypto::Cipher::decrypt(std::istream&,
std::ostream&, Poco::Crypto::Cipher::Encoding) (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D0EE7:
Poco::Crypto::Cipher::decryptString(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
Poco::Crypto::Cipher::Encoding) (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x39FE59D: CRYPT::decrypt(CRYPT::RSAKey const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) (RSA.C:311)
==45293==
abn the propsed suppression like this:
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:BN_bin2bn
fun:BN_rand
fun:bn_rand_range
fun:BN_BLINDING_create_param
fun:RSA_setup_blinding
fun:rsa_get_blinding
fun:RSA_eay_private_decrypt
obj:/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48
fun:_ZN4Poco6Crypto15CryptoStreamBuf5closeEv
fun:_ZN4Poco6Crypto6Cipher7decryptERSiRSoNS1_8EncodingE
fun:_ZN4Poco6Crypto6Cipher13decryptStringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_8EncodingE
fun:_ZN5CRYPT7decryptERKNS_6RSAKeyERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
}
As there are many different BN_* functions causing these errors I would
like to use a global suppression. I tried:
{
crypto2
Memcheck:Cond
obj: */libcrypto.so.1.0.0
}
and
{
crypto2
Memcheck:Cond
...
obj: */libPocoCrypto64.so.*
}
and many variations of these. Only individual ones like
{
bn
Memcheck:Cond
fun:BN_bin2bn
}
do work.
Any hints from your side ?
I am using Valgrind-3.13.0 on CentOS 7 (RHEL 7) with Linux_x86_64.
Many thanks
Dominik
|
|
From: YuGiOhJCJ Mailing-L. <yug...@la...> - 2017-08-24 08:33:57
|
The solution is to rebuild my testing program: $ gcc main.c $ valgrind ./a.out ==19235== Memcheck, a memory error detector ==19235== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==19235== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==19235== Command: ./a.out ==19235== hello world ==19235== ==19235== HEAP SUMMARY: ==19235== in use at exit: 0 bytes in 0 blocks ==19235== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==19235== ==19235== All heap blocks were freed -- no leaks are possible ==19235== ==19235== For counts of detected and suppressed errors, rerun with: -v ==19235== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Problem solved. On Thu, 24 Aug 2017 07:52:08 +0000 YuGiOhJCJ Mailing-List via Valgrind-users <val...@li...> wrote: > Hello, > > I have recently built my own package of glibc instead of using the one provided by my operating system. > > The result is that valgrind is now complaining: > --- > $ valgrind ./a.out > ==1445== Memcheck, a memory error detector > ==1445== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==1445== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info > ==1445== Command: ./a.out > ==1445== > > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strlen > valgrind: in an object with soname matching: ld-linux.so.2 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux.so.2 > valgrind: > valgrind: Possible fixes: (1, short term): install glibc's debuginfo > valgrind: package on this machine. (2, longer term): ask the packagers > valgrind: for your Linux distribution to please in future ship a non- > valgrind: stripped ld.so (or whatever the dynamic linker .so is called) > valgrind: that exports the above-named function using the standard > valgrind: calling conventions for this platform. The package you need > valgrind: to install for fix (1) is called > valgrind: > valgrind: On Debian, Ubuntu: libc6-dbg > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > valgrind: > valgrind: Cannot continue -- exiting now. Sorry. > --- > > It seems that valgrind requires to not strip the dynamic linker. > It's true that in my glibc package, I have stripped it: > --- > $ file /lib64/ld-2.26.so > /lib64/ld-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped > --- > > So, I have rebuilt my own package of glibc without stripping the dynamic linker. > Here, you can see, it is no longer stripped: > --- > $ file /lib64/ld-2.26.so > /lib64/ld-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped > --- > > However, valgrind is still complaining: > --- > $ valgrind ./a.out > ==1445== Memcheck, a memory error detector > ==1445== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==1445== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info > ==1445== Command: ./a.out > ==1445== > > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strlen > valgrind: in an object with soname matching: ld-linux.so.2 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux.so.2 > valgrind: > valgrind: Possible fixes: (1, short term): install glibc's debuginfo > valgrind: package on this machine. (2, longer term): ask the packagers > valgrind: for your Linux distribution to please in future ship a non- > valgrind: stripped ld.so (or whatever the dynamic linker .so is called) > valgrind: that exports the above-named function using the standard > valgrind: calling conventions for this platform. The package you need > valgrind: to install for fix (1) is called > valgrind: > valgrind: On Debian, Ubuntu: libc6-dbg > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > valgrind: > valgrind: Cannot continue -- exiting now. Sorry. > --- > > Why valgrind is still complaining please? > > Thank you. > Best regards. > > ------------------------------------------------------------------------------ > 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 |
|
From: YuGiOhJCJ Mailing-L. <yug...@la...> - 2017-08-24 08:17:20
|
Hello, I have recently built my own package of glibc instead of using the one provided by my operating system. The result is that valgrind is now complaining: --- $ valgrind ./a.out ==1445== Memcheck, a memory error detector ==1445== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1445== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1445== Command: ./a.out ==1445== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. --- It seems that valgrind requires to not strip the dynamic linker. It's true that in my glibc package, I have stripped it: --- $ file /lib64/ld-2.26.so /lib64/ld-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped --- So, I have rebuilt my own package of glibc without stripping the dynamic linker. Here, you can see, it is no longer stripped: --- $ file /lib64/ld-2.26.so /lib64/ld-2.26.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped --- However, valgrind is still complaining: --- $ valgrind ./a.out ==1445== Memcheck, a memory error detector ==1445== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1445== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1445== Command: ./a.out ==1445== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. --- Why valgrind is still complaining please? Thank you. Best regards. |
|
From: Felix R. <fe...@kn...> - 2017-08-21 13:51:24
|
Hi guys,
I think I have fixed it: I did not include the copy of bbIn->offsIP.
Thank you!
On 2017-08-21 14:55, Felix Rubio wrote:
> Hi everybody
>
> I am trying to make a simple pass-through tool, in which BB's are
> just copied. I am using valgrind 3.13.0, and this is the code I have
> in my tool. Can somebody give me a hand?
>
> Thank you!
> Felix
>
> static IRSB *my_instrument (VgCallbackClosure *closure, IRSB *bbIn,
> const VexGuestLayout *layout, const VexGuestExtents *vge, const
> VexArchInfo * vai, const IRType gWordTy, IRType hWordTy)
> {
> IRSB *bbOut = emptyIRSB ();
> bbOut->tyenv = deepCopyIRTypeEnv (bbIn->tyenv);
> bbOut->next = deepCopyIRExpr (bbIn->next);
> bbOut->jumpkind = bbIn->jumpkind;
>
> for (Int i = 0; i < bbIn->stmts_used; ++i)
> {
> IRStmt* const st = bbIn->stmts[i];
> addStmtToIRSB(bbOut, st);
> }
> return bbOut;
>
> }
>
>
> ------------------------------------------------------------------------------
> 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
|
|
From: Felix R. <fe...@kn...> - 2017-08-21 13:12:44
|
Hi everybody
I am trying to make a simple pass-through tool, in which BB's are
just copied. I am using valgrind 3.13.0, and this is the code I have in
my tool. Can somebody give me a hand?
Thank you!
Felix
static IRSB *my_instrument (VgCallbackClosure *closure, IRSB *bbIn,
const VexGuestLayout *layout, const VexGuestExtents *vge, const
VexArchInfo * vai, const IRType gWordTy, IRType hWordTy)
{
IRSB *bbOut = emptyIRSB ();
bbOut->tyenv = deepCopyIRTypeEnv (bbIn->tyenv);
bbOut->next = deepCopyIRExpr (bbIn->next);
bbOut->jumpkind = bbIn->jumpkind;
for (Int i = 0; i < bbIn->stmts_used; ++i)
{
IRStmt* const st = bbIn->stmts[i];
addStmtToIRSB(bbOut, st);
}
return bbOut;
}
|
|
From: John R. <jr...@bi...> - 2017-08-21 12:12:17
|
> ==8061== Invalid read of size 1
> ==8061== at 0x4EC0F63: ??? (in /usr/lib/R/lib/libR.so)
>
> ...
>> ==8061== Address 0x4231f7a3c8360000 is not stack'd, malloc'd or (recently) free'd
>
> yes, this is the first complaint from valgrind.
Running on valgrind-3.11.0 on x86_64 under Linux under Xen [as shown
elsewhere, which I have not quoted.]
The latest version of valgrind is valgrind-3.13.0 (two versions newer
than 3.11.0), so you should upgrade; although I would guess that
it might not make any difference in this particular case.
>
> When the code crashes, the gdb terminal takes control and gives the following message:
>
> *Program received signal SIGTRAP, Trace/breakpoint trap.*
> *0x0000000004ec0f63 in ?? () from /usr/lib/R/lib/libR.so*
>
> Executing the command *(gdb) shell cat /proc/1668/maps *gives the following information(i've taken an excerpt from the message):
>
> *00400000-00401000 r-xp 00000000 ca:01 108910 /usr/lib/R/bin/exec/R*
[[snip]]
> *052f4000-052ff000 rw-p 002ba000 ca:01 108931 /usr/lib/R/lib/libR.so*
The hope was that "cat /proc/PID/maps" might show something with an address
that is related to 0x4231f7a3c8360000; but I don't see anything like that
in what you report. When interpreted as a double precision number,
then the bits 0x4231f7a3c8360000 are approximately 4.76987e+18,
which looks "random" to me. However, the least-significant bits
are 16 zero bits (0x...0000) which does look less-than-random.
In your first message of this thread:
> I have written a lengthy C function and called it in my R script
> within a repeat loop, up till 5th iteration, the loop executes properly.
> In the 6th iteration, my R studio crashes. The last line that is executed
> before the crash is third line after the function call. In this line
> I am assigning a list from the C function to an R object.
"... assigning a list from the C function to an R object" might require
special handling. What does the documentation for Rstudio say
about such conversions involving non-atomic data (a list, as opposed
to a floating-point value)? Your function might have to build the list
one element at a time, or call a special function inside Rstudio
in order to allocate space for the list. A plain "malloc(...)"
in your C function might not be good enough to interoperate with Rstudio.
So at this point, it seems to me that you should find an example
where someone else has a plugin C function that creates a list of
floating-point values [possibly using malloc() in C], and returns
that list to Rstdio. Adapt your code based on that example.
In particular, construct the list using the same method. The
numerical values of the elements will be different, of course.
--
|
|
From: IMoL <im...@gm...> - 2017-08-20 01:05:02
|
Done - thank you for looking into it John. https://bugs.kde.org/show_bug.cgi?id=383723 Please let me know if there's anything else I can do. - Andy On Sat, Aug 19, 2017 at 5:07 PM, John Reiser <jr...@bi...> wrote: > - (again this is macOS 10.12.x) >> - in Qt Creator, add a new project >> - select "Qt Console Application" >> - edit its qmake file to remove "CONFIG += console" (this shouldn't be >> added on the Mac) >> - build "Profile" version >> >> >> The .pro looks like this: >> > [[snip]] > > Thank you for providing the reproducible test case. It helps > *tremendously*! > Action: Please file a bug report (see http://valgrind.org/support/bu > g_reports.html). > Use the title "MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 > opcode" or similar. > Include (copy+paste) your test case and the analysis below. A bug report > gets > on the authoritative list of things to do; the mailing lists are ephemeral. > > > I was able to reproduce the problem using --tool=none, so it is not > specific > to memcheck, callgrind, etc. I am running MacOS Sierra Version 10.12.6. > The code in system library libdispatch.dylib expects there to be a trap > handler for opcode 'ud2' (0f 0b) [generates SIGILL] which the valgrind > emulator has disabled through some means, perhaps unknowing or inadvertent. > [Or, perhaps some even-more-global protocol (that would have avoided the > 'ud2') > has been violated.] > ===== > $ valgrind --tool=none ~jreiser/build-valgrind_test2- > Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2 > ==43499== Nulgrind, the minimal Valgrind tool > ==43499== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. > ==43499== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for > copyright info > ==43499== Command: /Users/jreiser/build-valgrind_ > test2-Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2 > ==43499== > --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option > --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 > times) > --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 > times) > UNKNOWN workq_ops option 128 > ==43499== valgrind: Unrecognised instruction at address 0x103b1fb50. > ==43499== at 0x103B1FB50: _dispatch_kq_init (in > /usr/lib/system/libdispatch.dylib) > ==43499== by 0x103B1D8FB: _dispatch_client_callout (in > /usr/lib/system/libdispatch.dylib) > [[snip]] > ===== > > Running valgrind under lldb, and disassembling after the SIGILL: > ===== > (lldb) x/12i 0x103b1fb1f > 0x103b1fb1f: e8 2e 48 02 00 callq 0x103b44352 > 0x103b1fb24: 83 f8 ff cmpl $-0x1, %eax > 0x103b1fb27: 0f 85 a1 00 00 00 jne 0x103b1fbce > 0x103b1fb2d: e8 e8 46 02 00 callq 0x103b4421a > 0x103b1fb32: 48 63 00 movslq (%rax), %rax > 0x103b1fb35: 48 83 f8 04 cmpq $0x4, %rax > 0x103b1fb39: 74 bf je 0x103b1fafa > 0x103b1fb3b: 48 8d 0d dd 71 02 00 leaq 0x271dd(%rip), %rcx > 0x103b1fb42: 48 89 0d f7 cc 04 00 movq %rcx, 0x4ccf7(%rip) > 0x103b1fb49: 48 89 05 20 cd 04 00 movq %rax, 0x4cd20(%rip) > => 0x103b1fb50: 0f 0b ud2 > 0x103b1fb52: f6 03 01 testb $0x1, (%rbx) > ===== > Obviously %rax and %rcx (and/or 64-bit memory locations > (0x4ccf7+0x103b1fb49) > and (0x4cd20+0x103b1fb50)) contain two parameters to some subroutine > that is invoked by the signal handler for the 'ud2' opcode (which generates > SIGILL or its MacOS equivalent). So perhaps valgrind should restore > the original signal handler for SIGILL during the single instruction 'ud2'; > or, libdispatch.dylib may be assuming some other protocol that valgrind > does not know about, etc. > > > > Details: > I had only XCode already installed. It took a couple hours to download > and install the free version of QtCreator (default version 5.9.1), > then install MacPorts and homebrew (following > https://paolozaino.wordpress.com/2015/05/05/how-to-install-a > nd-use-autotools-on-mac-os-x/ > which aroused suspicion because the most recent update was a couple years > old) > so that I could run autogen.sh to build valgrind from current git source. > But I did manage to reproduce the problem, so enough of everything > probably worked. > > > -- > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: John R. <jr...@bi...> - 2017-08-19 21:07:23
|
> - (again this is macOS 10.12.x) > - in Qt Creator, add a new project > - select "Qt Console Application" > - edit its qmake file to remove "CONFIG += console" (this shouldn't be added on the Mac) > - build "Profile" version > > > The .pro looks like this: [[snip]] Thank you for providing the reproducible test case. It helps *tremendously*! Action: Please file a bug report (see http://valgrind.org/support/bug_reports.html). Use the title "MacOS 10.12.x: UNKNOWN workq_ops option 128, and ud2 opcode" or similar. Include (copy+paste) your test case and the analysis below. A bug report gets on the authoritative list of things to do; the mailing lists are ephemeral. I was able to reproduce the problem using --tool=none, so it is not specific to memcheck, callgrind, etc. I am running MacOS Sierra Version 10.12.6. The code in system library libdispatch.dylib expects there to be a trap handler for opcode 'ud2' (0f 0b) [generates SIGILL] which the valgrind emulator has disabled through some means, perhaps unknowing or inadvertent. [Or, perhaps some even-more-global protocol (that would have avoided the 'ud2') has been violated.] ===== $ valgrind --tool=none ~jreiser/build-valgrind_test2-Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2 ==43499== Nulgrind, the minimal Valgrind tool ==43499== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==43499== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info ==43499== Command: /Users/jreiser/build-valgrind_test2-Desktop_Qt_5_9_1_clang_64bit-Profile/valgrind_test2 ==43499== --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times) --43499-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times) UNKNOWN workq_ops option 128 ==43499== valgrind: Unrecognised instruction at address 0x103b1fb50. ==43499== at 0x103B1FB50: _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) ==43499== by 0x103B1D8FB: _dispatch_client_callout (in /usr/lib/system/libdispatch.dylib) [[snip]] ===== Running valgrind under lldb, and disassembling after the SIGILL: ===== (lldb) x/12i 0x103b1fb1f 0x103b1fb1f: e8 2e 48 02 00 callq 0x103b44352 0x103b1fb24: 83 f8 ff cmpl $-0x1, %eax 0x103b1fb27: 0f 85 a1 00 00 00 jne 0x103b1fbce 0x103b1fb2d: e8 e8 46 02 00 callq 0x103b4421a 0x103b1fb32: 48 63 00 movslq (%rax), %rax 0x103b1fb35: 48 83 f8 04 cmpq $0x4, %rax 0x103b1fb39: 74 bf je 0x103b1fafa 0x103b1fb3b: 48 8d 0d dd 71 02 00 leaq 0x271dd(%rip), %rcx 0x103b1fb42: 48 89 0d f7 cc 04 00 movq %rcx, 0x4ccf7(%rip) 0x103b1fb49: 48 89 05 20 cd 04 00 movq %rax, 0x4cd20(%rip) => 0x103b1fb50: 0f 0b ud2 0x103b1fb52: f6 03 01 testb $0x1, (%rbx) ===== Obviously %rax and %rcx (and/or 64-bit memory locations (0x4ccf7+0x103b1fb49) and (0x4cd20+0x103b1fb50)) contain two parameters to some subroutine that is invoked by the signal handler for the 'ud2' opcode (which generates SIGILL or its MacOS equivalent). So perhaps valgrind should restore the original signal handler for SIGILL during the single instruction 'ud2'; or, libdispatch.dylib may be assuming some other protocol that valgrind does not know about, etc. Details: I had only XCode already installed. It took a couple hours to download and install the free version of QtCreator (default version 5.9.1), then install MacPorts and homebrew (following https://paolozaino.wordpress.com/2015/05/05/how-to-install-and-use-autotools-on-mac-os-x/ which aroused suspicion because the most recent update was a couple years old) so that I could run autogen.sh to build valgrind from current git source. But I did manage to reproduce the problem, so enough of everything probably worked. -- |
|
From: IMoL <im...@gm...> - 2017-08-19 13:35:59
|
Thanks John.
"/bin/date" works (which is not surprising as I think workq_ops is related
to threads?)
- (again this is macOS 10.12.x)
- in Qt Creator, add a new project
- select "Qt Console Application"
- edit its qmake file to remove "CONFIG += console" (this shouldn't be
added on the Mac)
- build "Profile" version
The .pro looks like this:
QT += core
QT -= gui
CONFIG += c++11
TARGET = valgrind-test2
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp
And main.cpp looks like this:
#include <QCoreApplication>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
return a.exec();
}
Run valgrind --tool=callgrind <path-to-command-line-executable>
Results:
==35785== Callgrind, a call-graph generating cache profiler
==35785== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et
al.
==35785== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright
info
==35785== Command:
/Users/maloney/dev/build-valgrind-test2-Qt_5_x-Profile/valgrind-test2
==35785==
==35785== For interactive control, run 'callgrind_control -h'.
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2
times)
--35785-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4
times)
UNKNOWN workq_ops option 128
==35785== valgrind: Unrecognised instruction at address 0x103b0fb50.
==35785== at 0x103B0FB50: _dispatch_kq_init (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8B8: dispatch_once_f (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0FA90: _dispatch_kq_update (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B110CD: _dispatch_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B1103D: _dispatch_source_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B10E85: _dispatch_source_kevent_register (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B20651: _dispatch_queue_resume_finalize_activation (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103E603C0: _notify_lib_init (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x103E609AB: notify_register_dispatch (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x1027E8916: CFUniCharMapTo (in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== Your program just tried to execute an instruction that Valgrind
==35785== did not recognise. There are two possible reasons for this.
==35785== 1. Your program has a bug and erroneously jumped to a non-code
==35785== location. If you are running Memcheck and you just saw a
==35785== warning about a bad jump, it's probably your program's fault.
==35785== 2. The instruction is legitimate but Valgrind doesn't handle it,
==35785== i.e. it's Valgrind's fault. If you think this is the case or
==35785== you are not sure, please let us know and we'll try to fix it.
==35785== Either way, Valgrind will now raise a SIGILL signal which will
==35785== probably kill your program.
==35785==
==35785== Process terminating with default action of signal 4 (SIGILL)
==35785== Illegal opcode at address 0x103B0FB50
==35785== at 0x103B0FB50: _dispatch_kq_init (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0D8B8: dispatch_once_f (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B0FA90: _dispatch_kq_update (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B110CD: _dispatch_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B1103D: _dispatch_source_kevent_resume (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B10E85: _dispatch_source_kevent_register (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103B20651: _dispatch_queue_resume_finalize_activation (in
/usr/lib/system/libdispatch.dylib)
==35785== by 0x103E603C0: _notify_lib_init (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x103E609AB: notify_register_dispatch (in
/usr/lib/system/libsystem_notify.dylib)
==35785== by 0x1027E8916: CFUniCharMapTo (in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==35785== by 0x103B0D8FB: _dispatch_client_callout (in
/usr/lib/system/libdispatch.dylib)
==35785==
==35785== Events : Ir
==35785== Collected : 188406082
==35785==
==35785== I refs: 188,406,082
Illegal instruction: 4
On Sat, Aug 19, 2017 at 9:14 AM, John Reiser <jr...@bi...> wrote:
> 3. This is a Qt-based application
>>
>
> Find the smallest (shortest) executable which triggers the problem.
> Does /bin/date work under your callgrind? Does a "null" Qt-based app
> suffer?
> (Something like "BEGIN END;" or "{ }" with "no content": you get the idea.)
> Post it here so that anyone can reproduce the problem.
>
> --
>
> ------------------------------------------------------------
> ------------------
> 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
>
|
188 messages has been excluded from this view by a project administrator.
