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
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tom H. <to...@co...> - 2022-08-03 16:33:26
|
No, it's clone3: https://bugs.kde.org/show_bug.cgi?id=420906 Tom On 03/08/2022 17:30, Mark Roberts wrote: > Just tried running the Valgrind test suite on WSL2 (win 10, Ubuntu 22.04). > I'm not surprised that there were lots of failures. But the majority were: > WARNING: unhandled amd64-linux syscall: 435 > > I suspect WSL is not a platform you care much about, but looking at syswrap > for Darwin I see this might be pid hibernate? Would it be difficult to add > support for this? > > Thank you, > Mark > > -----Original Message----- > From: Mark Wielaard [mailto:ma...@kl...] > Sent: Monday, August 1, 2022 4:56 AM > To: Tom Hughes <to...@co...>; Mark Roberts <ma...@cs...>; > val...@li... > Subject: Re: [Valgrind-users] new error message from Valgrind > > On Thu, 2022-07-28 at 22:22 +0100, Tom Hughes via Valgrind-users wrote: >> On 28/07/2022 21:39, Mark Roberts wrote: >>> I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a >>> new error message from Valgrind: >>> >>> --915-- WARNING: unhandled amd64-linux syscall: 334 >>> >>> --915-- You may be able to write your own handler. >>> >>> --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. >>> >>> --915-- Nevertheless we consider this a bug. Please report >>> >>> --915-- it at http://valgrind.org/support/bug_reports.html >>> <http://valgrind.org/support/bug_reports.html>. >>> >>> Using same version of Valgrind as before (3.17). >>> >>> Any ideas as to what’s happening? >> >> Yes, your libc has started trying to use rseq. >> >> It's harmless - the next version of valgrind will silently reject it >> with ENOSYS which is what is happening now anyway just with a warning. > > Where the next version of valgrind is 3.19.0 which is already released (in > April). So you might just want to upgrade your valgrind. > > If you want to backport to older versions then the commit that got rid of > the warning was: > > commit 1024237358f01009fe233cb1294f3b8211304eaa > Author: Mark Wielaard <ma...@kl...> > Date: Fri Dec 10 17:41:59 2021 +0100 > > Implement linux rseq syscall as ENOSYS > > This implements rseq for amd64, arm, arm64, ppc32, ppc64, > s390x and x86 linux as ENOSYS (without warning). > > glibc will start using rseq to accelerate sched_getcpu, if > available. This would cause a warning from valgrind every > time a new thread is started. > > Real rseq (restartable sequences) support is pretty hard, so > for now just explicitly return ENOSYS (just like we do for clone3). > > > https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html > > Cheers, > > Mark -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Mark W. <ma...@kl...> - 2022-08-01 11:56:17
|
On Thu, 2022-07-28 at 22:22 +0100, Tom Hughes via Valgrind-users wrote: > On 28/07/2022 21:39, Mark Roberts wrote: > > I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a > > new > > error message from Valgrind: > > > > --915-- WARNING: unhandled amd64-linux syscall: 334 > > > > --915-- You may be able to write your own handler. > > > > --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > > > > --915-- Nevertheless we consider this a bug. Please report > > > > --915-- it at http://valgrind.org/support/bug_reports.html > > <http://valgrind.org/support/bug_reports.html>. > > > > Using same version of Valgrind as before (3.17). > > > > Any ideas as to what’s happening? > > Yes, your libc has started trying to use rseq. > > It's harmless - the next version of valgrind will silently > reject it with ENOSYS which is what is happening now anyway > just with a warning. Where the next version of valgrind is 3.19.0 which is already released (in April). So you might just want to upgrade your valgrind. If you want to backport to older versions then the commit that got rid of the warning was: commit 1024237358f01009fe233cb1294f3b8211304eaa Author: Mark Wielaard <ma...@kl...> Date: Fri Dec 10 17:41:59 2021 +0100 Implement linux rseq syscall as ENOSYS This implements rseq for amd64, arm, arm64, ppc32, ppc64, s390x and x86 linux as ENOSYS (without warning). glibc will start using rseq to accelerate sched_getcpu, if available. This would cause a warning from valgrind every time a new thread is started. Real rseq (restartable sequences) support is pretty hard, so for now just explicitly return ENOSYS (just like we do for clone3). https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html Cheers, Mark |
|
From: Tom H. <to...@co...> - 2022-07-28 21:23:19
|
On 28/07/2022 21:39, Mark Roberts wrote: > I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a new > error message from Valgrind: > > --915-- WARNING: unhandled amd64-linux syscall: 334 > > --915-- You may be able to write your own handler. > > --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > > --915-- Nevertheless we consider this a bug. Please report > > --915-- it at http://valgrind.org/support/bug_reports.html > <http://valgrind.org/support/bug_reports.html>. > > Using same version of Valgrind as before (3.17). > > Any ideas as to what’s happening? Yes, your libc has started trying to use rseq. It's harmless - the next version of valgrind will silently reject it with ENOSYS which is what is happening now anyway just with a warning. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Mark R. <ma...@cs...> - 2022-07-28 21:09:58
|
I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a new error message from Valgrind: --915-- WARNING: unhandled amd64-linux syscall: 334 --915-- You may be able to write your own handler. --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --915-- Nevertheless we consider this a bug. Please report --915-- it at http://valgrind.org/support/bug_reports.html. Using same version of Valgrind as before (3.17). Any ideas as to what’s happening? Thank you, Mark |
|
From: Mark W. <ma...@kl...> - 2022-07-27 11:43:43
|
It has been twenty years today since Valgrind 1.0 was released. Make sure to read Nicholas Nethercote’s Twenty years of Valgrind: https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html And learn about the early days, Valgrind "skins", the influence Valgrind had on raising the bar when it comes to correctness for C and C++ programs, and why a hacker on the Rust programming language still uses Valgrind. Happy birthday, Valgrind! |
|
From: John R. <jr...@bi...> - 2022-07-26 02:21:01
|
> Does memcheck include support for per-thread caching (now enabled by default in glibc)? Memcheck intercepts all calls on allocation and free-ing subroutines (malloc, free, calloc, realloc, memalign, posix_memalign, brk, sbrk, mmap, ...) and totally replaces each one with code that is internal to memcheck. The glibc routines never are called at all. Also, memcheck serializes all execution, and executes code from only one thread at a time. |
|
From: Glenn H. <gle...@gm...> - 2022-07-26 01:52:48
|
Does memcheck include support for per-thread caching (now enabled by default in glibc)? ᐧ |
|
From: Julian S. <jse...@gm...> - 2022-07-14 09:51:05
|
On 13/07/2022 16:38, Bresalier, Rob (Nokia - US/Murray Hill) wrote: > We are trying to track down a suspected place in our code that keeps accumulating memory in a 'still reachable'. It sounds like you're trying to track down a "process lifetime" leak. You'd be better off using one of the heap profiling tools for that, either massif (--tool=massif) or dhat (--tool=dhat), but probably massif. You'll need to ask your package manager to install the massif-visualizer GUI. Run with --tool=massif --num-callers=12 (or 16 or whatever). Use the GUI to look at the resulting profile. After a bit of poking around it should be obvious where all your allocation is coming from. J |
|
From: John R. <jr...@bi...> - 2022-07-14 02:13:28
|
> 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. It would take around one hour or less to *produce* the complete report without printing it. Re-direct stderr to a file, or use command-line options --xml-fd= or --xml-file=. See "valgrind --help" and/or the user manual for other options to control error reporting. Using any text editor on the report file, or inserting the 'sed' (or 'awk') stream editor into the pipeline of error output, enables filtering the error reports. > 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. Note that all the excluded reports (counts 1 through 99) have only 1 or 2 characters in their decimal representation, so you don't even need to convert the field to a number to decide. > If not possible without patching valgrind, any hints on where I could patch valgrind to accomplish this? Find the source location which prints the instance count, and adjust the code. This is "standard engineering effort" for a programmer who is adept at using 'grep', even without prior experience with the source code of valgrind. |
|
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. |
188 messages has been excluded from this view by a project administrator.
