|
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: 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 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: 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-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 |