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
(1) |
Dec
|
|
From: Bresalier, R. (N. - US/M. Hill) <rob...@no...> - 2022-07-13 20:12:02
|
We are trying to track down a suspected place in our code that keeps accumulating memory in a 'still reachable'. When I turn on still reachable and run my process for a few hours and then stop the process to get the valgrind reports there are over 2.7 million loss records which are mostly still reachables. It would take forever for valgrind to print this out. The large majority of "still reachable" that I want to ignore allocate just a few blocks. I would like to suppress these and only output "still reachables" that allocated 100 blocks or more. The suppression mechanism seems to only be to suppress particular backtraces. But I would like to suppress based on number of blocks instead, suppress loss records with a small number of blocks. Is this possible to suppress based on block count without patching valgrind? If not possible without patching valgrind, any hints on where I could patch valgrind to accomplish this? Thanks, Rob |
|
From: Cédric P. <cp...@se...> - 2022-07-12 15:46:13
|
> > I have 2 different boards running QNX 6.5 and mounting the exact same file system. > > One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument AM3352. > > Since both SoC share the same instruction set (Cortex A8 - amv7le), they can run the same binaries. > > > > However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes on the AM3352 : > > ==1863697== Process terminating with default action of signal 11 > > (SIGSEGV): dumping core ==1863697== Bad permissions for mapped region at address 0x245C > > ==1863697== at 0x1E4CC: mprotect (mprotect.c:33 in /proc/boot/libc.so.3) > Run valgrind with "-d -d -d -v -v -v" and compare the two systems, paying particular attention to differences that involve "aspacem". Comparing output for iMX53 and AM3352, here is what I noticed : 1) aspacem lines are very similar (some values slightly change but not that much), except for those 2 lines : AM3352: aspacem 5: file 0000100000-0000100fff 4096 r-x-- d=0x409 i=103748 o=0 m=0 fnIdx=1 fname="/bin/echo" aspacem 6: file 0000101000-0000101fff 4096 rw--- d=0x409 i=103748 o=0 m=0 fnIdx=1 fname="/bin/echo" iMX53 : aspacem 5: file 0000100000-0000100fff 4096 r-x-- d=0x803 i=2951 o=0 m=0 fnIdx=1 fname="/bin/echo" aspacem 6: file 0000101000-0000101fff 4096 rw--- d=0x803 i=2951 o=0 m=0 fnIdx=1 fname="/bin/echo" 2) After the list of "Adding active redirection: ..." for each syscall (free, malloc, mallopt, bcopy, memcmp ...), it seems that we reach the crash : AM3352: REDIR: 0x261a8 (libc.so.3:mallopt) redirected to 0x85b74 (mallopt) gdbsrv VG core calling VG_(gdbserver_report_signal) vki_nr 11 SIGSEGV gdb_nr 11 SIGSEGV tid 1 iMX53 : REDIR: 0x5c484 (libc.so.3:memset) redirected to 0x88ce8 (memset) REDIR: 0x5cb34 (libc.so.3:strlen) redirected to 0x881c8 (strlen) REDIR: 0x5c6b4 (libc.so.3:strcmp) redirected to 0x886bc (strcmp) REDIR: 0x28714 (libc.so.3:malloc) redirected to 0x86928 (malloc) mallocfr newSuperblock at 0x102000 (pszB 4194288) owner CLIENT/client ... To be honest, I don't know how to interpret this. I don't even understand why REDIR in not called for "mallopt" on iMX53. > Does your QNX have tools such as gdb and strace or dtrace? > It will be helpful to know the address mappings at the time of the SIGSEGV. Yes, QNX have such tools. I tried to use vgdb and gdb, but I don't get ... anything ... (no backtrace, no info address, no info mem ...) (gdb) target remote 192.168.98.50:2346 Remote debugging using 192.168.98.50:2346 warning: Can not parse XML target description; XML support was disabled at compile time [New Thread 1] [Switching to Thread 1] 0x0003a190 in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0001e4cc in ?? () (gdb) bt #0 0x0001e4cc in ?? () (gdb) info meminfo (gdb) I also recorded kernel and scheduling events but the only information I got is that during 5 seconds memcheck-arm-nto works a lot, and does a lot of read(), write() and fseek() calls. Finally, a signal 11 is received and a lot of close() calls are done and ... that's all. I suppose it doesn't help you that much ... -- _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@bi...> - 2022-07-11 14:34:13
|
> I have 2 different boards running QNX 6.5 and mounting the exact same file system. > One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument AM3352. > Since both SoC share the same instruction set (Cortex A8 - amv7le), they can run the same binaries. > > However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes on the AM3352 : > ==1863697== Process terminating with default action of signal 11 (SIGSEGV): dumping core > ==1863697== Bad permissions for mapped region at address 0x245C > ==1863697== at 0x1E4CC: mprotect (mprotect.c:33 in /proc/boot/libc.so.3) Run valgrind with "-d -d -d -v -v -v" and compare the two systems, paying particular attention to differences that involve "aspacem". Does your QNX have tools such as gdb and strace or dtrace? It will be helpful to know the address mappings at the time of the SIGSEGV. -- |
|
From: Cédric P. <cp...@se...> - 2022-07-11 12:53:09
|
> > Hi Valgrind community, > > > > I have 2 different boards running QNX 6.5 and mounting the exact same file system. > > One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument AM3352. > > Since both SoC share the same instruction set (Cortex A8 - amv7le), they can run the same binaries. > > > > However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes on the AM3352 : > Hi Cedric > 3.10 is quite old, can you try a newer version? No I cannot. The version of Valgrind I use was ported on QNX in 2015 by open QNX community (https://community.qnx.com/sf/go/projects.valgrind/frs.valgrind.valgrind_3_10) and, as far as I know, no newer version was ported since. > Also I recommend starting with the simplest thing possible (I see that you tried with echo, but I recommend using just "--tool=none" and no other options). Excellent idea. If I use "--tool=none", valgrind does not crash anymore (and I suppose it doesn't do much). At least, it seems to mean that the problem is linked to the tool I use. However, for all other tools I try (massif, drd, helgrind, exp-dhat) I face the same crash. > A+ > Paul _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Floyd, P. <pj...@wa...> - 2022-07-11 08:16:42
|
On 2022-07-11 09:43, Cédric Perles wrote: > Hi Valgrind community, > > I have 2 different boards running QNX 6.5 and mounting the exact same file system. > One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument AM3352. > Since both SoC share the same instruction set (Cortex A8 - amv7le), they can run the same binaries. > > However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes on the AM3352 : > Hi Cedric 3.10 is quite old, can you try a newer version? Also I recommend starting with the simplest thing possible (I see that you tried with echo, but I recommend using just "--tool=none" and no other options). A+ Paul |
|
From: Cédric P. <cp...@se...> - 2022-07-11 07:59:12
|
Hi Valgrind community, I have 2 different boards running QNX 6.5 and mounting the exact same file system. One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument AM3352. Since both SoC share the same instruction set (Cortex A8 - amv7le), they can run the same binaries. However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes on the AM3352 : pendant:/bin>/usr/bin/valgrind --tool=memcheck --allow-mismatched-debuginfo=yes --extra-debuginfo-path=/usr/lib/debug/ echo ==1863697== Memcheck, a memory error detector ==1863697== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==1863697== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==1863697== Command: echo ==1863697== ==1863697== ==1863697== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==1863697== Bad permissions for mapped region at address 0x245C ==1863697== at 0x1E4CC: mprotect (mprotect.c:33 in /proc/boot/libc.so.3) ==1863697== by 0x25B03: _band_get_aligned (band.c:450 in /proc/boot/libc.so.3) ==1863697== by 0x77383: ??? (in /proc/boot/libc.so.3) ==1863697== ==1863697== HEAP SUMMARY: ==1863697== in use at exit: 0 bytes in 0 blocks ==1863697== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1863697== ==1863697== All heap blocks were freed -- no leaks are possible ==1863697== ==1863697== For counts of detected and suppressed errors, rerun with: -v ==1863697== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Memory fault It always crashes the same way, whatever the binary I analyse. I am clueless, I don't understand how it can work on iMX53 and fail on AM3352 with the same file system (same binaries, same libs, same scripts, same conf ...). Does somebody have an idea ? Best regards, Cédric |
|
From: Mathieu M. <ma...@de...> - 2022-07-01 10:17:42
|
On Wed, Jun 29, 2022 at 8:49 PM John Reiser <jr...@bi...> wrote: > > > Program received signal SIGILL, Illegal instruction. > > vgPlain_am_startup (sp_at_startup=3204445696) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > 1626 init_nsegment(&seg); > > (gdb) x/i $pc > > => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000 > > > As a reminder I do not have neon on this machine: > > > > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > > idivt vfpd32 lpae > > Therefore this is a gcc configuration problem. Whoever configured the gcc > that was used to compile your valgrind assumed that neon would be present, > but your machine lacks neon. > > Run "gcc --verbose". On my RaspberryPi Model 2B I get (wrapped by hand > to reasonable line length): > ----- > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper > Target: arm-linux-gnueabihf > Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' \ > --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs \ > --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr \ > --with-gcc-major-version-only --program-suffix=-10 --program-prefix=arm-linux-gnueabihf- \ > --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext \ > --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new \ > --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support \ > --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release \ > --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions \ > --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror \ > --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf \ > --target=arm-linux-gnueabihf > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 10.2.1 20210110 (Debian 10.2.1-6) > ----- > where the important part now is "--with-arch=armv7-a --with-fpu=vfpv3-d16" > for which the "-d16" part restricts gcc to 16 double precision registers > even though my hardware has "vfpd32". > > Consulting "info gcc", then searching for "neon", and examining "ARM Options", > it seems to me that the fix for gcc to assume vfp3 floating point with 32 double- > precision registers and the half-precision floating-point conversion operations, > but omit neon, is the gcc command-line parameter "-march=armv7-a+vfpv3-fp16+nosimd". > You may want to use "-d16" somewhere, too. Discussing the issue with Debian/gcc/armhf maintainer resulted in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014091#12 So here is my suggested patch for valgrind: https://bugs.kde.org/show_bug.cgi?id=456200#c1 Thanks everyone for your help ! |
|
From: John R. <jr...@bi...> - 2022-06-29 18:48:33
|
> Program received signal SIGILL, Illegal instruction. > vgPlain_am_startup (sp_at_startup=3204445696) at > m_aspacemgr/aspacemgr-linux.c:1626 > 1626 init_nsegment(&seg); > (gdb) x/i $pc > => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000 > As a reminder I do not have neon on this machine: > > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > idivt vfpd32 lpae Therefore this is a gcc configuration problem. Whoever configured the gcc that was used to compile your valgrind assumed that neon would be present, but your machine lacks neon. Run "gcc --verbose". On my RaspberryPi Model 2B I get (wrapped by hand to reasonable line length): ----- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' \ --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs \ --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr \ --with-gcc-major-version-only --program-suffix=-10 --program-prefix=arm-linux-gnueabihf- \ --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext \ --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu \ --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new \ --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support \ --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release \ --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions \ --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror \ --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf \ --target=arm-linux-gnueabihf Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) ----- where the important part now is "--with-arch=armv7-a --with-fpu=vfpv3-d16" for which the "-d16" part restricts gcc to 16 double precision registers even though my hardware has "vfpd32". Consulting "info gcc", then searching for "neon", and examining "ARM Options", it seems to me that the fix for gcc to assume vfp3 floating point with 32 double- precision registers and the half-precision floating-point conversion operations, but omit neon, is the gcc command-line parameter "-march=armv7-a+vfpv3-fp16+nosimd". You may want to use "-d16" somewhere, too. |
|
From: Tom H. <to...@co...> - 2022-06-29 15:06:06
|
On 29/06/2022 15:49, Mathieu Malaterre wrote:
> Here is what I get on first try:
>
> Program received signal SIGILL, Illegal instruction.
> vgPlain_am_startup (sp_at_startup=3204445696) at
> m_aspacemgr/aspacemgr-linux.c:1626
> 1626 init_nsegment(&seg);
> (gdb) x/i $pc
> => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
> (gdb) x/12i $pc-6*4
> 0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>: eoreq
> r6, lr, r4, lsr #6
> 0x5807107c <vgPlain_am_startup>: push {r4, r5, r6, r7, r8,
> r9, r10, r11, lr}
> 0x58071080 <vgPlain_am_startup+4>: sub sp, sp, #68 ; 0x44
> 0x58071084 <vgPlain_am_startup+8>: add r8, sp, #8
> 0x58071088 <vgPlain_am_startup+12>: mov r4, r0
> 0x5807108c <vgPlain_am_startup+16>: bl 0x5807611c
> <vgModuleLocal_am_segnames_init>
> => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
> 0x58071094 <vgPlain_am_startup+24>: mov lr, r8
> 0x58071098 <vgPlain_am_startup+28>: mov r3, #0
> 0x5807109c <vgPlain_am_startup+32>: mov r10, #1
> 0x580710a0 <vgPlain_am_startup+36>: str r3, [sp, #56] ; 0x38
> 0x580710a4 <vgPlain_am_startup+40>: mvn r2, #0
> (gdb) x/12xw $pc-6*4
> 0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>:
> 0x002e6324 0xe92d4ff0 0xe24dd044 0xe28d8008
> 0x58071088 <vgPlain_am_startup+12>: 0xe1a04000 0xeb001422
> 0xf2c00010 0xe1a0e008
> 0x58071098 <vgPlain_am_startup+28>: 0xe3a03000 0xe3a0a001
> 0xe58d3038 0xe3e02000
> (gdb) info reg
> r0 0x4 4
> r1 0x0 0
> r2 0x5850a0e8 1481679080
> r3 0x5850a0f8 1481679096
> r4 0xbefff600 3204445696
> r5 0x58606388 1482711944
> r6 0xbefff600 3204445696
> r7 0x58260000 1478885376
> r8 0x58708258 1483768408
> r9 0x58708354 1483768660
> r10 0x0 0
> r11 0x587083ac 1483768748
> r12 0x5870a3b4 1483776948
> sp 0x58708250 0x58708250 <vgPlain_interim_stack+1056416>
> lr 0x58071090 1476858000
> pc 0x58071090 0x58071090 <vgPlain_am_startup+20>
> cpsr 0x80000010 -2147483632
> fpscr 0x0 0
> (gdb) x/16xw $sp
> 0x58708250 <vgPlain_interim_stack+1056416>: 0x00000000
> 0x00000000 0x00000000 0x00000000
> 0x58708260 <vgPlain_interim_stack+1056432>: 0x00000000
> 0x00000000 0x00000000 0x00000000
> 0x58708270 <vgPlain_interim_stack+1056448>: 0x00000000
> 0x00000000 0x00000000 0x0013296c
> 0x58708280 <vgPlain_interim_stack+1056464>: 0xbefff604
> 0xbefff600 0x58260000 0x581fea9c
>
> As a reminder I do not have neon on this machine:
>
> Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
> idivt vfpd32 lpae
Right but you are apparently using a valgrind that was compiled
to target a machine that does have neon, hence your problem.
If you compiled it yourself then you need to change your compiler
options to correctly target the architecture you are running on
and if you got precompiled binaries from somewhere then I'm afraid
they're not compatible with your machine.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Mathieu M. <ma...@de...> - 2022-06-29 14:50:17
|
On Wed, Jun 29, 2022 at 4:27 PM John Reiser <jr...@bi...> wrote:
> -----
> (gdb) run args...
> Program received signal SIGILL, Illegal instruction.
> (gdb) x/i $pc ## the faulting instruction
> (gdb) x/12i pc-6*4 ## disassemble the surrounding instructions
> (Gdb) x/12xw $pc-6*4 ## and in 32-bit raw hexadecimal
> (gdb) info reg ## content of all registers
> (gdb) x/16xw $sp ## dump the active end of the stack
> (gdb) bt ## source-level backtrace
> -----
Here is what I get on first try:
Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445696) at
m_aspacemgr/aspacemgr-linux.c:1626
1626 init_nsegment(&seg);
(gdb) x/i $pc
=> 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
(gdb) x/12i $pc-6*4
0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>: eoreq
r6, lr, r4, lsr #6
0x5807107c <vgPlain_am_startup>: push {r4, r5, r6, r7, r8,
r9, r10, r11, lr}
0x58071080 <vgPlain_am_startup+4>: sub sp, sp, #68 ; 0x44
0x58071084 <vgPlain_am_startup+8>: add r8, sp, #8
0x58071088 <vgPlain_am_startup+12>: mov r4, r0
0x5807108c <vgPlain_am_startup+16>: bl 0x5807611c
<vgModuleLocal_am_segnames_init>
=> 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
0x58071094 <vgPlain_am_startup+24>: mov lr, r8
0x58071098 <vgPlain_am_startup+28>: mov r3, #0
0x5807109c <vgPlain_am_startup+32>: mov r10, #1
0x580710a0 <vgPlain_am_startup+36>: str r3, [sp, #56] ; 0x38
0x580710a4 <vgPlain_am_startup+40>: mvn r2, #0
(gdb) x/12xw $pc-6*4
0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>:
0x002e6324 0xe92d4ff0 0xe24dd044 0xe28d8008
0x58071088 <vgPlain_am_startup+12>: 0xe1a04000 0xeb001422
0xf2c00010 0xe1a0e008
0x58071098 <vgPlain_am_startup+28>: 0xe3a03000 0xe3a0a001
0xe58d3038 0xe3e02000
(gdb) info reg
r0 0x4 4
r1 0x0 0
r2 0x5850a0e8 1481679080
r3 0x5850a0f8 1481679096
r4 0xbefff600 3204445696
r5 0x58606388 1482711944
r6 0xbefff600 3204445696
r7 0x58260000 1478885376
r8 0x58708258 1483768408
r9 0x58708354 1483768660
r10 0x0 0
r11 0x587083ac 1483768748
r12 0x5870a3b4 1483776948
sp 0x58708250 0x58708250 <vgPlain_interim_stack+1056416>
lr 0x58071090 1476858000
pc 0x58071090 0x58071090 <vgPlain_am_startup+20>
cpsr 0x80000010 -2147483632
fpscr 0x0 0
(gdb) x/16xw $sp
0x58708250 <vgPlain_interim_stack+1056416>: 0x00000000
0x00000000 0x00000000 0x00000000
0x58708260 <vgPlain_interim_stack+1056432>: 0x00000000
0x00000000 0x00000000 0x00000000
0x58708270 <vgPlain_interim_stack+1056448>: 0x00000000
0x00000000 0x00000000 0x0013296c
0x58708280 <vgPlain_interim_stack+1056464>: 0xbefff604
0xbefff600 0x58260000 0x581fea9c
As a reminder I do not have neon on this machine:
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
idivt vfpd32 lpae
Also as a reminder, I cannot reproduce the above symptoms on a
different machine (with neon):
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
Thanks again for your kind help,
|
|
From: John R. <jr...@bi...> - 2022-06-29 14:27:31
|
> I did not make up those strace logs in my head, all I am trying to do > is Debian bug triaging. Turns out I did a pretty bad job at it: > > 1. The original Debian bug report seems to be PEBCAK, and I'll close > the bug as wontfix ASAP, > 2. I was not paying attention to the gcc version I was using. The original bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 specified the reproducing case "valgrind /bin/true". That now works for me: ----- $ valgrind /bin/true ==399== Memcheck, a memory error detector ==399== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==399== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==399== Command: /bin/true ==399== ==399== ==399== HEAP SUMMARY: ==399== in use at exit: 0 bytes in 0 blocks ==399== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==399== ==399== All heap blocks were freed -- no leaks are possible ==399== ==399== For lists of detected and suppressed errors, rerun with: -s ==399== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ----- in the environment: ----- $ valgrind --version valgrind-3.20.0.GIT $ gcc --version gcc (Debian 10.2.1-6) 10.2.1 20210110 $ uname -a Linux rpi2-20220121 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux ----- so the original bug report can be closed with "fixed in newer version" or something like that. > So if my understanding is correct I can make valgrind produce this > "Illegal instruction" using either gcc-11 or gcc-12 (Debian package > from sid), BUT I can make valgrind run using gcc-10 (again Debian > package from sid). This also seems to be hardware specific since armhf > binary + gcc-12 runs properly on arm64 (armhf chroot). Is it easy to install several versions (gcc-10, gcc-11, gcc-12, clang-13) at the same time, and switch among them by using something like CC=/path/to/gcc-12 ./configure Where can I find hints about this? > > Would you kindly indicate if you believe the bug should be reported > back to valgrind bug tracker or gcc bug tracker ? If that matters, > clang 13.0 seems to also mess up valgrind code and binaries produced > return this "Illegal instruction". SIGILL should be diagnosed using gdb to print the instruction stream and register contents ----- (gdb) run args... Program received signal SIGILL, Illegal instruction. (gdb) x/i $pc ## the faulting instruction (gdb) x/12i pc-6*4 ## disassemble the surrounding instructions (Gdb) x/12xw $pc-6*4 ## and in 32-bit raw hexadecimal (gdb) info reg ## content of all registers (gdb) x/16xw $sp ## dump the active end of the stack (gdb) bt ## source-level backtrace ----- But with valgrind you must just "continue" the deliberate SIGILL and SIGSEGV that valgrind uses. Here is an actual run: ----- $ gdb valgrind GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Reading symbols from valgrind... (gdb) run /bin/true Starting program: /usr/local/bin/valgrind /bin/true process 426 is executing new program: /usr/local/libexec/valgrind/memcheck-arm-linux Program received signal SIGILL, Illegal instruction. vgPlain_machine_get_hwcaps () at m_machine.c:1719 1719 __asm__ __volatile__(".word 0xF3044F54"); /* VMAXNM.F32 q2,q2,q2 */ ## Notice that this SIGILL is from valgrind trying to determine ## the actual hardware capabilities. Valgrind knows what it is doing, ## so just 'continue' to let valgrind handle the SIGILL. (gdb) c Continuing. ==426== Memcheck, a memory error detector ==426== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==426== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==426== Command: /bin/true ==426== Program received signal SIGSEGV, Segmentation fault. ## valgrind deliberate 0x62c68cc0 in ?? () (gdb) x/i $pc => 0x62c68cc0: str r3, [r9] (gdb) p $r9 $1 = 3187663772 (gdb) p/x $r9 $2 = 0xbdffe39c (gdb) x/12i $pc-6*4 0x62c68ca8: ldr r3, [r8, #424] ; 0x1a8 0x62c68cac: mov r1, r3 0x62c68cb0: movw r2, #62156 ; 0xf2cc 0x62c68cb4: movt r2, #22528 ; 0x5800 0x62c68cb8: blx r2 0x62c68cbc: ldr r3, [r8, #24] => 0x62c68cc0: str r3, [r9] 0x62c68cc4: add r7, r9, #4 0x62c68cc8: mov r0, r7 0x62c68ccc: ldr r3, [r8, #428] ; 0x1ac 0x62c68cd0: mov r1, r3 0x62c68cd4: movw r2, #62156 ; 0xf2cc (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. ## valgrind deliberate 0x62c6cc0c in ?? () (gdb) x/i $pc => 0x62c6cc0c: str r9, [r11] (gdb) x/12i $pc-6*4 0x62c6cbf4: ldr r9, [r8, #416] ; 0x1a0 0x62c6cbf8: mov r1, r9 0x62c6cbfc: movw r2, #62156 ; 0xf2cc 0x62c6cc00: movt r2, #22528 ; 0x5800 0x62c6cc04: blx r2 0x62c6cc08: ldr r9, [r8, #16] => 0x62c6cc0c: str r9, [r11] 0x62c6cc10: add r9, r11, #4 0x62c6cc14: mov r0, r9 0x62c6cc18: ldr r3, [r8, #420] ; 0x1a4 0x62c6cc1c: mov r1, r3 0x62c6cc20: movw r2, #62156 ; 0xf2cc (gdb) c Continuing. ==426== ==426== HEAP SUMMARY: ==426== in use at exit: 0 bytes in 0 blocks ==426== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==426== ==426== All heap blocks were freed -- no leaks are possible ==426== ==426== For lists of detected and suppressed errors, rerun with: -s ==426== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) [Inferior 1 (process 426) exited normally] ----- You also can use something like objdump --disassemble=subroutine_name to be sure that the executing process matches the built software file. Right now I cannot reproduce SIGILL, so I cannot dig in further. Based on the software that I built and ran: valgrind is not to blame; the problem lies with the compiler, operating system, or hardware. (In the last two months I have had four hardware failures: a 5-port ethernet switch, the sound output on a 12-year old consumer desktop PC, the sound output on a 5-year old self-built x86_64 desktop, and the power brick for a RaspberryPi.) |
|
From: Mathieu M. <ma...@de...> - 2022-06-29 10:09:39
|
On Tue, Jun 28, 2022 at 8:55 PM John Reiser <jr...@bi...> wrote: > > >> $ export RPI_MODEL=3 > >> $ export DEBIAN_RELEASE=bullseye > >> $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz > > > > That gives arm64, not armhf (32-bit). > > Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz > and running 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux > on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU): > ----- > model name : ARMv7 Processor rev 5 (v7l) > BogoMIPS : 44.80 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part : 0xc07 > CPU revision : 5 > ----- > with valgrind source > ----- > commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, origin/HEAD) > Author: Mark Wielaard <snip> > Date: Sat Jun 18 15:30:54 2022 +0200 > ----- > and ignoring a build failure > ----- > Making install in tests > make[3]: Entering directory '.../valgrind/cachegrind/tests' > make[3]: *** No rule to make target 'install'. Stop. > ----- > then I see: > ----- > $ ldd /bin/date > linux-vdso.so.1 (0xbeed6000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000) > /lib/ld-linux-armhf.so.3 (0xb6f9c000) > $ type valgrind > valgrind is hashed (/usr/local/bin/valgrind) > $ valgrind --version > valgrind-3.20.0.GIT > $ valgrind /bin/date > ==32179== Memcheck, a memory error detector > ==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info > ==32179== Command: /bin/date > ==32179== > Tue Jun 28 18:50:27 UTC 2022 > ==32179== > ==32179== HEAP SUMMARY: > ==32179== in use at exit: 64 bytes in 1 blocks > ==32179== total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated > ==32179== > ==32179== LEAK SUMMARY: > ==32179== definitely lost: 64 bytes in 1 blocks > ==32179== indirectly lost: 0 bytes in 0 blocks > ==32179== possibly lost: 0 bytes in 0 blocks > ==32179== still reachable: 0 bytes in 0 blocks > ==32179== suppressed: 0 bytes in 0 blocks > ==32179== Rerun with --leak-check=full to see details of leaked memory > ==32179== > ==32179== For lists of detected and suppressed errors, rerun with: -s > ==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > $ > ----- Point taken, I did not do my homework correctly, sorry for losing your time. > So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point). I did not make up those strace logs in my head, all I am trying to do is Debian bug triaging. Turns out I did a pretty bad job at it: 1. The original Debian bug report seems to be PEBCAK, and I'll close the bug as wontfix ASAP, 2. I was not paying attention to the gcc version I was using. So if my understanding is correct I can make valgrind produce this "Illegal instruction" using either gcc-11 or gcc-12 (Debian package from sid), BUT I can make valgrind run using gcc-10 (again Debian package from sid). This also seems to be hardware specific since armhf binary + gcc-12 runs properly on arm64 (armhf chroot). Would you kindly indicate if you believe the bug should be reported back to valgrind bug tracker or gcc bug tracker ? If that matters, clang 13.0 seems to also mess up valgrind code and binaries produced return this "Illegal instruction". Thanks for your time |
|
From: John R. <jr...@bi...> - 2022-06-28 18:54:29
|
>> $ export RPI_MODEL=3 >> $ export DEBIAN_RELEASE=bullseye >> $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz > > That gives arm64, not armhf (32-bit). Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz and running 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU): ----- model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 44.80 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 ----- with valgrind source ----- commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, origin/HEAD) Author: Mark Wielaard <snip> Date: Sat Jun 18 15:30:54 2022 +0200 ----- and ignoring a build failure ----- Making install in tests make[3]: Entering directory '.../valgrind/cachegrind/tests' make[3]: *** No rule to make target 'install'. Stop. ----- then I see: ----- $ ldd /bin/date linux-vdso.so.1 (0xbeed6000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000) /lib/ld-linux-armhf.so.3 (0xb6f9c000) $ type valgrind valgrind is hashed (/usr/local/bin/valgrind) $ valgrind --version valgrind-3.20.0.GIT $ valgrind /bin/date ==32179== Memcheck, a memory error detector ==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==32179== Command: /bin/date ==32179== Tue Jun 28 18:50:27 UTC 2022 ==32179== ==32179== HEAP SUMMARY: ==32179== in use at exit: 64 bytes in 1 blocks ==32179== total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated ==32179== ==32179== LEAK SUMMARY: ==32179== definitely lost: 64 bytes in 1 blocks ==32179== indirectly lost: 0 bytes in 0 blocks ==32179== possibly lost: 0 bytes in 0 blocks ==32179== still reachable: 0 bytes in 0 blocks ==32179== suppressed: 0 bytes in 0 blocks ==32179== Rerun with --leak-check=full to see details of leaked memory ==32179== ==32179== For lists of detected and suppressed errors, rerun with: -s ==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) $ ----- So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point). |
|
From: John R. <jr...@bi...> - 2022-06-28 16:32:09
|
> $ export RPI_MODEL=3 > $ export DEBIAN_RELEASE=bullseye > $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz That gives arm64, not armhf (32-bit). |
|
From: Mathieu M. <ma...@de...> - 2022-06-28 15:05:42
|
On Tue, Jun 28, 2022 at 4:54 PM John Reiser <jr...@bi...> wrote: > > track down Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 > which is 3 years old: > ----- > Installed libc6 version: libc6-dgb:armhf 2.28-8 > > valgrind /bin/true > > ==12463== Memcheck, a memory error detector > ==12463== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==12463== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > 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: index > valgrind: in an object with soname matching: ld-linux-armhf.so.3 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux-armhf.so.3 > ----- > > Using valgrind 3.19.0 on Debian/sid : > % dpkg --print-architecture > armhf > % cat /proc/cpuinfo | grep vfpv3 | head -1 > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > idivt vfpd32 lpae > > % ./memcheck/memcheck-arm-linux > > zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux > > > > Just in case that help, here is the gdb output (*) > > > > Let me know if you need more output. > > > > (*) > > % gdb ./memcheck/memcheck-arm-linux > > GNU gdb (Debian 12.1-2) 12.1 > > > (gdb) r > > Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux > > > > Program received signal SIGILL, Illegal instruction. > > vgPlain_am_startup (sp_at_startup=3204445840) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > 1626 init_nsegment(&seg); > > (gdb) bt full > > #0 vgPlain_am_startup (sp_at_startup=3204445840) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0, > > ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx = > > -1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&', > > hasT = 88 'X', isCH = 164 '\244'} > > suggested_clstack_end = <optimized out> > > __PRETTY_FUNCTION__ = "vgPlain_am_startup" > > > I tried to reproduce the reported behavior of valgrind-3.19.0 on my system : > ----- /proc/cpuinfo > model name : ARMv7 Processor rev 4 (v7l) > BogoMIPS : 51.20 > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part : 0xd03 > CPU revision : 4 > ----- > $ uname -a > Linux f33arm32 5.9.14-200.fc33.armv7hl #1 SMP Fri Dec 11 15:02:36 UTC 2020 armv7l armv7l armv7l GNU/Linux > $ ldd /bin/date > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f6a000) > libc.so.6 => /lib/libc.so.6 (0xb6e14000) > /lib/ld-linux-armhf.so.3 (0xb6fbe000) > > So the name of ld-linux contains 'armhf', although the Linux kernel is 'armv7l'. > The Features line of /proc/cpuinfo is not quite equivalent: > Mathieu's: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae > mine: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 > > Re-building the software: > ----- > $ wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 > $ tar xf valgrind-3.19.0.tar.bz2 > $ cd valgrind-3.19.0 > $ ./configure > $ make -j4 > $ file ./memcheck/memcheck-arm-linux > ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2880b8ee178c482a9de58e83b161a0b38ca008ff, with debug_info, not stripped > $ ./memcheck/memcheck-arm-linux > valgrind: You cannot run './memcheck/memcheck-arm-linux' directly. > valgrind: You should use $prefix/bin/valgrind. > $ sudo make install > $ /usr/local/bin/valgrind --version > valgrind-3.19.0 > $ /usr/local/bin/valgrind /bin/date > ==14541== Memcheck, a memory error detector > ==14541== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==14541== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info > ==14541== Command: /bin/date > ==14541== > Tue Jun 28 07:40:14 AM PDT 2022 > ==14541== > ==14541== HEAP SUMMARY: > ==14541== in use at exit: 0 bytes in 0 blocks > ==14541== total heap usage: 427 allocs, 427 frees, 30,017 bytes allocated > ==14541== > ==14541== All heap blocks were freed -- no leaks are possible > ==14541== > ==14541== For lists of detected and suppressed errors, rerun with: -s > ==14541== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > $ > ----- > > So, valgrind-3.19.0 works for me. I cannot reproduce the original bad behavior, nor the SIGILL, > on my hardware running 5.9.14-200.fc33.armv7hl. Ok, thanks for the quick answer. I discovered that I was supposed to run 'vg-in-place' when not using make install. Here is my strace output (*) > If you believe that my Fedora33 environment is not close enough to your Debian/sid, > then please give the URL of a raw image for RaspberryPi Model 3 V1.2 that I can install > on a 32GB SDHC card. Can you try: $ export RPI_MODEL=3 $ export DEBIAN_RELEASE=bullseye $ wget https://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz See complete instructions at: https://wiki.debian.org/RaspberryPiImages Thanks -again- (*) this is from a git/master as of today: % strace ./vg-in-place execve("./vg-in-place", ["./vg-in-place"], 0xbe95c740 /* 19 vars */) = 0 brk(NULL) = 0x1bbd000 uname({sysname="Linux", nodename="abel", ...}) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fbb000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=17519, ...}) = 0 mmap2(NULL, 17519, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6fb6000 close(3) = 0 openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0y}\1\0004\0\0\0"..., 512) = 512 statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=983540, ...}) = 0 mmap2(NULL, 1073552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e8a000 mprotect(0xb6f77000, 61440, PROT_NONE) = 0 mmap2(0xb6f86000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xec000) = 0xb6f86000 mmap2(0xb6f89000, 29072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f89000 close(3) = 0 set_tls(0xb6fbbe20) = 0 mprotect(0xb6f86000, 8192, PROT_READ) = 0 mprotect(0x4ee000, 4096, PROT_READ) = 0 mprotect(0xb6fbd000, 4096, PROT_READ) = 0 munmap(0xb6fb6000, 17519) = 0 getuid32() = 3180 getgid32() = 3180 getpid() = 7762 rt_sigaction(SIGCHLD, {sa_handler=0x4d9db9, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 geteuid32() = 3180 brk(NULL) = 0x1bbd000 brk(0x1bde000) = 0x1bde000 getppid() = 7759 statx(AT_FDCWD, "/home/malat/valgrind", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0 statx(AT_FDCWD, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0 openat(AT_FDCWD, "./vg-in-place", O_RDONLY|O_LARGEFILE) = 3 fcntl64(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 geteuid32() = 3180 getegid32() = 3180 rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGINT, {sa_handler=0x4d9db9, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 read(10, "#!/bin/sh\n\n# Figure out an absol"..., 8192) = 691 statx(AT_FDCWD, "./vg-in-place", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=691, ...}) = 0 pipe([3, 4]) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6fbb948) = 7763 close(4) = 0 read(3, "/home/malat/valgrind/.\n", 128) = 23 read(3, "", 128) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7763, si_uid=3180, si_status=0, si_utime=0, si_stime=0} --- sigreturn({mask=[]}) = 0 close(3) = 0 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 7763 wait4(-1, 0xbeeca264, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 vfork() = 7764 rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGILL}], 0, NULL) = 7764 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=7764, si_uid=3180, si_status=SIGILL, si_utime=0, si_stime=0} --- sigreturn({mask=[]}) = 7764 write(2, "Illegal instruction\n", 20Illegal instruction ) = 20 wait4(-1, 0xbeeca394, WNOHANG, NULL) = -1 ECHILD (No child processes) read(10, "", 8192) = 0 exit_group(132) = ? +++ exited with 132 +++ |
|
From: John R. <jr...@bi...> - 2022-06-28 14:53:54
|
track down Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 which is 3 years old: ----- Installed libc6 version: libc6-dgb:armhf 2.28-8 valgrind /bin/true ==12463== Memcheck, a memory error detector ==12463== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12463== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info 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: index valgrind: in an object with soname matching: ld-linux-armhf.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-armhf.so.3 ----- Using valgrind 3.19.0 on Debian/sid : % dpkg --print-architecture armhf % cat /proc/cpuinfo | grep vfpv3 | head -1 Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae > % ./memcheck/memcheck-arm-linux > zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux > > Just in case that help, here is the gdb output (*) > > Let me know if you need more output. > > (*) > % gdb ./memcheck/memcheck-arm-linux > GNU gdb (Debian 12.1-2) 12.1 > (gdb) r > Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux > > Program received signal SIGILL, Illegal instruction. > vgPlain_am_startup (sp_at_startup=3204445840) at > m_aspacemgr/aspacemgr-linux.c:1626 > 1626 init_nsegment(&seg); > (gdb) bt full > #0 vgPlain_am_startup (sp_at_startup=3204445840) at > m_aspacemgr/aspacemgr-linux.c:1626 > seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0, > ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx = > -1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&', > hasT = 88 'X', isCH = 164 '\244'} > suggested_clstack_end = <optimized out> > __PRETTY_FUNCTION__ = "vgPlain_am_startup" I tried to reproduce the reported behavior of valgrind-3.19.0 on my system : ----- /proc/cpuinfo model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 51.20 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 ----- $ uname -a Linux f33arm32 5.9.14-200.fc33.armv7hl #1 SMP Fri Dec 11 15:02:36 UTC 2020 armv7l armv7l armv7l GNU/Linux $ ldd /bin/date libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f6a000) libc.so.6 => /lib/libc.so.6 (0xb6e14000) /lib/ld-linux-armhf.so.3 (0xb6fbe000) So the name of ld-linux contains 'armhf', although the Linux kernel is 'armv7l'. The Features line of /proc/cpuinfo is not quite equivalent: Mathieu's: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae mine: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 Re-building the software: ----- $ wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 $ tar xf valgrind-3.19.0.tar.bz2 $ cd valgrind-3.19.0 $ ./configure $ make -j4 $ file ./memcheck/memcheck-arm-linux ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2880b8ee178c482a9de58e83b161a0b38ca008ff, with debug_info, not stripped $ ./memcheck/memcheck-arm-linux valgrind: You cannot run './memcheck/memcheck-arm-linux' directly. valgrind: You should use $prefix/bin/valgrind. $ sudo make install $ /usr/local/bin/valgrind --version valgrind-3.19.0 $ /usr/local/bin/valgrind /bin/date ==14541== Memcheck, a memory error detector ==14541== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==14541== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==14541== Command: /bin/date ==14541== Tue Jun 28 07:40:14 AM PDT 2022 ==14541== ==14541== HEAP SUMMARY: ==14541== in use at exit: 0 bytes in 0 blocks ==14541== total heap usage: 427 allocs, 427 frees, 30,017 bytes allocated ==14541== ==14541== All heap blocks were freed -- no leaks are possible ==14541== ==14541== For lists of detected and suppressed errors, rerun with: -s ==14541== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) $ ----- So, valgrind-3.19.0 works for me. I cannot reproduce the original bad behavior, nor the SIGILL, on my hardware running 5.9.14-200.fc33.armv7hl. If you believe that my Fedora33 environment is not close enough to your Debian/sid, then please give the URL of a raw image for RaspberryPi Model 3 V1.2 that I can install on a 32GB SDHC card. |
|
From: Mathieu M. <ma...@de...> - 2022-06-28 11:36:44
|
Hi John !
On Tue, Jun 28, 2022 at 1:16 PM John Reiser <jr...@bi...> wrote:
>
> On 6/28/22, Mathieu Malaterre wrote:
> > % strace ./memcheck/memcheck-arm-linux
> > execve("./memcheck/memcheck-arm-linux",
> > ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0
> > --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} ---
> > +++ killed by SIGILL +++
> > zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux
>
> memcheck wants determine the actual hardware capabilities.
> The description given by AT_PLATFORM, AT_HWCAP, AT_HWCAP2
> has not always been complete and correct, so memcheck
> tries the hardware instructions that matter, and memcheck
> is prepared to handle SIGILL if it occurs. Thus there
> are likely to be a few deliberate SIGILL near the beginning.
> If strace always halts upon SIGILL, without letting
> memcheck's handler catch the SIGILL and recover from it,
> then strace is too eager. For instance, on x86_64
> strace always aborts on 'int3' regardless of signal handlers.
Thanks for the detailed explanation. I must admit this is way too low
level stuff for me.
> What happens without using 'strace'?
Same symptoms (AFAIK):
% ./memcheck/memcheck-arm-linux
zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux
Just in case that help, here is the gdb output (*)
Let me know if you need more output.
(*)
% gdb ./memcheck/memcheck-arm-linux
GNU gdb (Debian 12.1-2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./memcheck/memcheck-arm-linux...
(gdb) r
Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux
Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
1626 init_nsegment(&seg);
(gdb) bt full
#0 vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0,
ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx =
-1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&',
hasT = 88 'X', isCH = 164 '\244'}
suggested_clstack_end = <optimized out>
__PRETTY_FUNCTION__ = "vgPlain_am_startup"
#1 0x580ccec4 in valgrind_main (envp=0xbefff69c, argv=0xbefff694,
argc=1) at m_main.c:1431
loglevel = <optimized out>
i = <optimized out>
vex_archinfo = {hwcaps = 1482711920, endness = 0, hwcache_info
= {num_levels = 0, num_caches = 0, caches = 0x0,
icaches_maintain_coherence = 0 '\000'}, ppc_icache_line_szB = 0,
ppc_dcbz_szB = 0,
ppc_scv_supported = 0 '\000', ppc_dcbzl_szB = 0,
arm64_dMinLine_lg2_szB = 0, arm64_iMinLine_lg2_szB = 0,
arm64_requires_fallback_LLSC = 0 '\000'}
need_help = <optimized out>
tid_main = 0
addr2dihandle = 0x0
wd = <optimized out>
need_help = <optimized out>
tid_main = <optimized out>
loglevel = <optimized out>
i = <optimized out>
addr2dihandle = <optimized out>
__PRETTY_FUNCTION__ = "valgrind_main"
vex_archinfo = <optimized out>
wd = <optimized out>
tmp_str = <optimized out>
res = <optimized out>
val = <optimized out>
res = <optimized out>
val = <optimized out>
s = <optimized out>
n = <optimized out>
res = <optimized out>
val = <optimized out>
s = <optimized out>
n = <optimized out>
val = <optimized out>
ok = <optimized out>
errmsg = <optimized out>
limLo = <optimized out>
limHi = <optimized out>
aLocal = <optimized out>
p = <optimized out>
cp = <optimized out>
vex_arch = <optimized out>
ok = <optimized out>
buf = <optimized out>
buf2 = <optimized out>
fd = <optimized out>
r = <optimized out>
nul = <optimized out>
exename = <optimized out>
client_auxv = <optimized out>
client_auxv_len = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
arg = <optimized out>
s = <optimized out>
ok = <optimized out>
seg_starts = <optimized out>
n_seg_starts = <optimized out>
anu = <optimized out>
change_ownership_v_c_OK = <optimized out>
co_start = <optimized out>
co_endPlus = <optimized out>
buf = <optimized out>
seg_starts = <optimized out>
n_seg_starts = <optimized out>
j = <optimized out>
n = <optimized out>
seg = <optimized out>
anl = <optimized out>
inaccessible_len = <optimized out>
seg = <optimized out>
seg = <optimized out>
#2 _start_in_C_linux (pArgc=0xbefff690) at m_main.c:3125
r = <optimized out>
argc = 1
argv = 0xbefff694
envp = 0xbefff69c
#3 0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
|
|
From: John R. <jr...@bi...> - 2022-06-28 11:16:31
|
On 6/28/22, Mathieu Malaterre wrote:
> % strace ./memcheck/memcheck-arm-linux
> execve("./memcheck/memcheck-arm-linux",
> ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0
> --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} ---
> +++ killed by SIGILL +++
> zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux
memcheck wants determine the actual hardware capabilities.
The description given by AT_PLATFORM, AT_HWCAP, AT_HWCAP2
has not always been complete and correct, so memcheck
tries the hardware instructions that matter, and memcheck
is prepared to handle SIGILL if it occurs. Thus there
are likely to be a few deliberate SIGILL near the beginning.
If strace always halts upon SIGILL, without letting
memcheck's handler catch the SIGILL and recover from it,
then strace is too eager. For instance, on x86_64
strace always aborts on 'int3' regardless of signal handlers.
What happens without using 'strace'?
|
|
From: Mathieu M. <ma...@de...> - 2022-06-28 07:42:56
|
Dear all, I am trying to track down Debian issue #928224. Here is what i did: % dpkg --print-architecture armhf % cat /proc/cpuinfo | grep vfpv3 | head -1 Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae % wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 % sha1sum valgrind-3.19.0.tar.bz2 294c341b421b4d9534e42e8125f509c148f48c17 valgrind-3.19.0.tar.bz2 % tar xf valgrind-3.19.0.tar.bz2 % cd valgrind-3.19.0 % ./configure % make % file ./memcheck/memcheck-arm-linux ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2babd38ca38e37093356f19df2485f4caf8eb1a0, with debug_info, not stripped % strace ./memcheck/memcheck-arm-linux execve("./memcheck/memcheck-arm-linux", ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0 --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} --- +++ killed by SIGILL +++ zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux Could someone confirm arm32/linux is supported in the latest release ? This is a Debian/sid system. Thanks much, |
|
From: $<ri...@nt...> - 2022-06-27 15:39:40
|
Used https://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip version where I am able to cross compile valgrind version 3.19.0 version without any problem. On Mon, Jun 27, 2022, 7:32 PM John Reiser <jr...@bi...> wrote: > On 6/27/22, $rik@nth wrote: > > Things got resolved after moving to older ndk where it supports gcc. > > Please state exactly which older version worked for you. > This will help other valgrind developers now, and encourage > maintainers to enhance future support so that the underlying > problem gets fixed. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2022-06-27 14:00:23
|
On 6/27/22, $rik@nth wrote: > Things got resolved after moving to older ndk where it supports gcc. Please state exactly which older version worked for you. This will help other valgrind developers now, and encourage maintainers to enhance future support so that the underlying problem gets fixed. |
|
From: $<ri...@nt...> - 2022-06-27 13:50:07
|
Things got resolved after moving to older ndk where it supports gcc. On Mon, Jun 27, 2022, 4:04 AM John Reiser <jr...@bi...> wrote: > > Upon moving to next. It landed into another issue. seems it is not easy > to cross compile the valgrind to Android as they mentioned > https://valgrind.org/docs/manual/dist.readme-android.html < > https://valgrind.org/docs/manual/dist.readme-android.html> > > > > Should i need to contact valgrind developers list to support. > > > > ../coregrind/link_tool_exe_linux 0x58000000 > /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang > -O3 --target=aarch64-linux-android31-clang > > > --gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ > --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot > -o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow > > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual > -Wwrite-strings -Wempty-body -Wformat -Wformat-security > -Wignored-qualifiers -Wenum-conversion -finline-functions > -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align > -Wno-self-assign -Wno-tautological-compare > > -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u > _start -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.o > memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o > memcheck_arm_linux-mc_main_asm.o memcheck_arm_linux-mc_translate.o > > memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o > ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a > > ld: error: undefined symbol: __aeabi_uidivmod > > >>> referenced by mc_leakcheck.c:837 > > >>> > memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > > >>> referenced by m_execontext.c:346 > > >>> > libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive > ../coregrind/libcoregrind-arm-linux.a > > >>> referenced by m_execontext.c:346 > > >>> > libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive > ../coregrind/libcoregrind-arm-linux.a > > >>> referenced 11 more times > > > [[snip]] > > You should contact whoever supports aarch64-linux-android31-clang and > complaln > that their linker step for static linking forgets to reference a static > library > that contains __aeabi_uidivmod, __aeabi_d2ulz, __aeabi_ul2d, > __aeabi_uldivmod, > __aeabi_uidiv, __aeabi_idiv, __aeabi_idivmod, and __aeabi_ldivmod . > > I found them in: > ----- > $ nm -gop --defined-only $(find . -name '*.a' 2>/dev/null) | grep > __aeabi_uidivmod > ./Android/Sdk/build-tools/32.0.0/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > ./Android/Sdk/build-tools/32.1.0-rc1/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > ./Android/Sdk/build-tools/30.0.3/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > $ > ----- > and similarly for the other undefined symbols. > > Therefore a workaround is to append explicit names for the files that > contain > those runtime symbols that you desire. > > The hint on how to investigate this problem is in > valgrind/coregrind/link_tool_exe_linux > which is a well-documented perl script that contains > ----- > # So: what we actually do: > # > # pass the specified command to the linker as-is, except, ... > > my $cmd = join(" ", @ARGV, "-static -Wl,-Ttext-segment=$ala"); > > #print "link_tool_exe_linux: $cmd\n"; > > > # Execute the command: > my $r = system($cmd); > ----- > which shows that aarch64-linux-android31-clang is at fault when static > linking. > (Forgetting the case of static linking is a common error in cross-building > systems.) > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2022-06-26 22:32:23
|
> Upon moving to next. It landed into another issue. seems it is not easy to cross compile the valgrind to Android as they mentioned https://valgrind.org/docs/manual/dist.readme-android.html <https://valgrind.org/docs/manual/dist.readme-android.html> > > Should i need to contact valgrind developers list to support. > > ../coregrind/link_tool_exe_linux 0x58000000 /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang -O3 --target=aarch64-linux-android31-clang > --gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare > -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.o memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o memcheck_arm_linux-mc_translate.o > memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a > ld: error: undefined symbol: __aeabi_uidivmod > >>> referenced by mc_leakcheck.c:837 > >>> memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > >>> referenced by m_execontext.c:346 > >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a > >>> referenced by m_execontext.c:346 > >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a > >>> referenced 11 more times > > [[snip]] You should contact whoever supports aarch64-linux-android31-clang and complaln that their linker step for static linking forgets to reference a static library that contains __aeabi_uidivmod, __aeabi_d2ulz, __aeabi_ul2d, __aeabi_uldivmod, __aeabi_uidiv, __aeabi_idiv, __aeabi_idivmod, and __aeabi_ldivmod . I found them in: ----- $ nm -gop --defined-only $(find . -name '*.a' 2>/dev/null) | grep __aeabi_uidivmod ./Android/Sdk/build-tools/32.0.0/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod ./Android/Sdk/build-tools/32.1.0-rc1/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod ./Android/Sdk/build-tools/30.0.3/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod $ ----- and similarly for the other undefined symbols. Therefore a workaround is to append explicit names for the files that contain those runtime symbols that you desire. The hint on how to investigate this problem is in valgrind/coregrind/link_tool_exe_linux which is a well-documented perl script that contains ----- # So: what we actually do: # # pass the specified command to the linker as-is, except, ... my $cmd = join(" ", @ARGV, "-static -Wl,-Ttext-segment=$ala"); #print "link_tool_exe_linux: $cmd\n"; # Execute the command: my $r = system($cmd); ----- which shows that aarch64-linux-android31-clang is at fault when static linking. (Forgetting the case of static linking is a common error in cross-building systems.) |
|
From: ellie <el...@ho...> - 2022-06-26 10:48:18
|
Oh I'm so silly, it appears I simply canceled the program seeing the SIGILL warning assuming it was just about to crash when I just would have needed to let it run. Thanks so much for explaining :-) For what it's worth, this is on an ARM64 Allwinner/PinePhone 1.2 CE 3GB RAM edition, so an early ARM64 architecture. I usually only use valgrind on my x64 desktop where there isn't any such SIGILL stuff, so that's why I'm not very familiar with it. On 6/26/22 10:52 AM, Tom Hughes wrote: > On 26/06/2022 09:13, ellie wrote: > >> How do I run openssl programs in valgrind on processors where it >> causes SIGILL? https://www.openssl.org/docs/faq.html#PROG17 > > In what way is it not working? > > When valgrind encounters an instruction it doesn't understand it > logs the details and then passes the SIGILL to and signal handler > which the application has registered exactly as openssl appears > to be expecting. > > Are you sure the SIGILL you're seeing is caused by openssl processor > feature detection and isn't just some other random instruction that > valgrind doesn't implement yet? What architecture is this? > > Tom > |
|
From: Mark W. <ma...@kl...> - 2022-06-26 10:16:45
|
Hi Ellie, On Sun, Jun 26, 2022 at 10:13:37AM +0200, ellie wrote: > How do I run openssl programs in valgrind on processors where it causes > SIGILL? https://www.openssl.org/docs/faq.html#PROG17 > > They recommend to use handle SIGILL nostop, but the only mention in the > valgrind documentation of that seems to be how to do this in gdb, not how to > do this in valgrind itself. Valgrind has (see the man page or manual): --sigill-diagnostics=<yes|no> [default: yes] Enable/disable printing of illegal instruction diagnostics. Enabled by default, but defaults to disabled when --quiet is given. The default can always be explicitly overridden by giving this option. When enabled, a warning message will be printed, along with some diagnostics, whenever an instruction is encountered that Valgrind cannot decode or translate, before the program is given a SIGILL signal. Often an illegal instruction indicates a bug in the program or missing support for the particular instruction in Valgrind. But some programs do deliberately try to execute an instruction that might be missing and trap the SIGILL signal to detect processor features. Using this flag makes it possible to avoid the diagnostic output that you would otherwise get in such cases. Hope that helps. Cheers, Mark |
188 messages has been excluded from this view by a project administrator.
