Created attachment 184335 [details] output of env command after sourcing SDK's environment setup script SUMMARY Environment: Target system/board is a i.MX93 (ARM A55) development board by PHYTEC, using Yocto/embedded Linux. Build-Toolchain is provided by PHYTEC, BSP-Yocto-NXP-i.MX93-PD24.2.2. $CC --version: aarch64-phytec-linux-gcc (GCC) 13.2.0 The set compiler command ($CC) and used arguments is exported as env.txt in the attachments after sourcing the SDK's environment-setup.sh script file. Problem description: Currently I want to debug a application which has a memory error (free(): invalid next size (fast) ), but valgrind failed with the unhandled instruction error mentioned in this bug report. We can't even get valgrind to run on our target system even with a simple hello-world program, if fails with the output below at OBSERVED RESULT. As we're quite new in the embedded Linux world, this may be a wrong set compiler flag or similar, but other programs cross-compiled work fine, so...we absolutely don't know what's going wrong for now. If you need any more logs, outputs or dumps, or have an idea what could be causing this problem, please let me know. I also built valgrind 3.25 from current Yocto recipe (https://git.yoctoproject.org/poky/plain/meta/recipes-devtools/valgrind/) , but this made no difference (this is the reason that in Valgrind's output the version 3.25 is mentioned, but the bug ticket is made for 3.22.0). If you need also the output of version 3.22, please let me know and I'll attach it. STEPS TO REPRODUCE 1. (Cross-) compiling a simple test application test.c : $CC test.c -o test 2. Copy it to target, run it there, everythings working: root@phyboard-nash-imx93-1:~# ./test Hello World! 3. Run valgrind on target platform: root@phyboard-nash-imx93-1:~# valgrind ./test OBSERVED RESULT root@phyboard-nash-imx93-1:~# valgrind ./test ==304== Memcheck, a memory error detector ==304== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==304== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info ==304== Command: ./test ==304== ARM64 front end: load_store disInstr(arm64): unhandled instruction disInstr(arm64): 1111'1000 1011'1111 1100'0010 0111'0011 ==304== valgrind: Unrecognised instruction at address 0x402b144. ==304== at 0x402B144: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4028A3F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4036EB3: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4022437: _dl_catch_exception (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x402255F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4036FC7: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4037E37: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x403A61B: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x40367B3: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4037C2F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x403BA13: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== Your program just tried to execute an instruction that Valgrind ==304== did not recognise. There are two possible reasons for this. ==304== 1. Your program has a bug and erroneously jumped to a non-code ==304== location. If you are running Memcheck and you just saw a ==304== warning about a bad jump, it's probably your program's fault. ==304== 2. The instruction is legitimate but Valgrind doesn't handle it, ==304== i.e. it's Valgrind's fault. If you think this is the case or ==304== you are not sure, please let us know and we'll try to fix it. ==304== Either way, Valgrind will now raise a SIGILL signal which will ==304== probably kill your program. ==304== ==304== Process terminating with default action of signal 4 (SIGILL): dumping core ==304== Illegal opcode at address 0x402B144 ==304== at 0x402B144: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4028A3F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4036EB3: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4022437: _dl_catch_exception (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x402255F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4036FC7: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4037E37: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x403A61B: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x40367B3: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x4037C2F: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== by 0x403BA13: ??? (in /usr/lib/ld-linux-aarch64.so.1) ==304== ==304== HEAP SUMMARY: ==304== in use at exit: 0 bytes in 0 blocks ==304== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==304== ==304== All heap blocks were freed -- no leaks are possible ==304== ==304== For lists of detected and suppressed errors, rerun with: -s ==304== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction (core dumped) EXPECTED RESULT A normal Valgrind run SOFTWARE/OS VERSIONS Build host: Linux / Ubuntu 22.04 LTS $uname -a: Linux vm-mbu 6.8.0-65-generic #68~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 15 18:06:34 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Target system: Linux phyboard-nash-imx93-1 6.6.52-gd9f64912-ge2f1c08f17a9 #1 SMP PREEMPT Tue Mar 11 14:20:47 UTC 2025 aarch64 GNU/Linux ADDITIONAL INFORMATION -
Created attachment 184336 [details] test.c
Created attachment 184337 [details] compiled test application
Created attachment 184338 [details] Valgrind core dump vgcore.304
Created attachment 184339 [details] Output of $CC -v -Q test.c -o test