[Bug]: _a.cxx_=`int main(int, const char **) {return 0;}`, `clang++ a.cxx`, `valgrind ./a.out`=`Unrecognised instruction at address X`

[SwuduSusuwu]

Problem description

For almost all terminals which compile sources, valgrind has lots of uses. But with Termux, valgrind always outputs Unrecognized instruction at address X

What steps will reproduce the bug?

Welcome to Termux!

Docs:       https://termux.dev/docs
Donate:     https://termux.dev/donate
Community:  https://termux.dev/community

Working with packages:

 - Search:  pkg search <query>
 - Install: pkg install <package>
 - Upgrade: pkg upgrade

Subscribing to additional repositories:

 - Root:    pkg install root-repo
 - X11:     pkg install x11-repo

For fixing any repository issues,
try 'termux-change-repo' command.

Report issues at https://termux.dev/issues
~ $ cat a.cxx
int main(int, const char **) {
        return 0;
}

~ $ clang++ a.cxx
~ $ ./a.out
~ $ valgrind ./a.out
==8263== Memcheck, a memory error detector
==8263== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==8263== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==8263== Command: ./a.out
==8263==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0x38BFC109
disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001
==8263== valgrind: Unrecognised instruction at address 0x4073170.
==8263==    at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64)
==8263== Your program just tried to execute an instruction that Valgrind
==8263== did not recognise.  There are two possible reasons for this.
==8263== 1. Your program has a bug and erroneously jumped to a non-code
==8263==    location.  If you are running Memcheck and you just saw a
==8263==    warning about a bad jump, it's probably your program's fault.
==8263== 2. The instruction is legitimate but Valgrind doesn't handle it,
==8263==    i.e. it's Valgrind's fault.  If you think this is the case or
==8263==    you are not sure, please let us know and we'll try to fix it.
==8263== Either way, Valgrind will now raise a SIGILL signal which will
==8263== probably kill your program.
==8263==
==8263== Process terminating with default action of signal 4 (SIGILL)
==8263==  Illegal opcode at address 0x4073170
==8263==    at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64)
==8263==    by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64)
==8263==
==8263== HEAP SUMMARY:
==8263==     in use at exit: 0 bytes in 0 blocks
==8263==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==8263==
==8263== All heap blocks were freed -- no leaks are possible
==8263==
==8263== For lists of detected and suppressed errors, rerun with: -s
==8263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
~ $

What is the expected behavior?

Without errors, executes this

System information

Termux Variables:
TERMUX_APK_RELEASE=F_DROID
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=30205
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://packages.termux.dev/apt/termux-main stable main
Updatable packages:
gh/stable 2.51.0 aarch64 [upgradable from: 2.50.0]
libxml2/stable 2.13.0 aarch64 [upgradable from: 2.12.7]
termux-tools version:
1.42.4
Android version:
14
Kernel build information:
Linux localhost 5.10.189-android13-4-00012-g1217bb583cc5-ab11174560 #1 SMP PREEMPT Mon Dec 4 18:59:42 UTC 2023 aarch64 Android
Device manufacturer:
Google
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
~/SubStack $

Can not update to Termux 0.120.0, can someone with 0.120.0 test this?

[SwuduSusuwu]

~ $ valgrind /bin/ls
==14222== Memcheck, a memory error detector
==14222== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==14222== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==14222== Command: /bin/ls
==14222==
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0x38BFC109
disInstr(arm64): 0011'1000 1011'1111 1100'0001 0000'1001
==14222== valgrind: Unrecognised instruction at address 0x4073170.
==14222==    at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64)
==14222== Your program just tried to execute an instruction that Valgrind
==14222== did not recognise.  There are two possible reasons for this.
==14222== 1. Your program has a bug and erroneously jumped to a non-code
==14222==    location.  If you are running Memcheck and you just saw a
==14222==    warning about a bad jump, it's probably your program's fault.
==14222== 2. The instruction is legitimate but Valgrind doesn't handle it,
==14222==    i.e. it's Valgrind's fault.  If you think this is the case or
==14222==    you are not sure, please let us know and we'll try to fix it.
==14222== Either way, Valgrind will now raise a SIGILL signal which will
==14222== probably kill your program.
==14222==
==14222== Process terminating with default action of signal 4 (SIGILL)
==14222==  Illegal opcode at address 0x4073170
==14222==    at 0x4073170: __dl__Z26__libc_safe_arc4random_bufPvm (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x4078377: __dl___libc_init_main_thread_late (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x410665F: __dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockR6soinfo (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x41065CB: __dl___linker_init (in /apex/com.android.runtime/bin/linker64)
==14222==    by 0x4048007: __dl__start (in /apex/com.android.runtime/bin/linker64)
==14222==
==14222== HEAP SUMMARY:
==14222==     in use at exit: 0 bytes in 0 blocks
==14222==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==14222==
==14222== All heap blocks were freed -- no leaks are possible
==14222==
==14222== For lists of detected and suppressed errors, rerun with: -s
==14222== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
~ $

[Grimler91]

The unrecognised instruction messages have been an issue for many years. I am under the impression that valgrind barely supports android, and I guess newer android versions might have made the situation even worse. You might have a better time using clang's memory sanitizer

[SwuduSusuwu]

Cool, wish for best with Clang's sanitizer. If no go, must wrap free/malloc/realloc? (Did this with a C project years ago, as a valgrind emu (Android did not have Termux, Terminal IDE did not have valgrind); did canaries too, to show buffler overruns/underruns): Wraps for function calls/returns allowed to produce stackstraces, but valgrind shows stackstraces, can use whatever already produces stackstraces? The most use was from the stackstraces. Perhaps just use intercept SIGILL with signal() to output stackstraces from OS?

For references: valgrind Bugzilla issue is https://bugs.kde.org/show_bug.cgi?id=488514

[SwuduSusuwu]

Project is cross platform thus want to support g++ / clang++. Searches for how to have -fsanitize compatible across g++ / clang++ found this: https://developers.redhat.com/blog/2021/05/05/memory-error-checking-in-c-and-c-comparing-sanitizers-and-valgrind

Sanitizers:

    Clang/GCC option:

    -fsanitize=address -fsanitize=undefined -fno-sanitize-recover=all -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fno-sanitize=null -fno-sanitize=alignment

    Copy snippet
    For LLDB/GDB and to prevent very short stack traces and usually false leaks detection:

    $ export ASAN_OPTIONS=abort_on_error=1:fast_unwind_on_malloc=0:detect_leaks=0 UBSAN_OPTIONS=print_stacktrace=1

    Copy snippet
    Fix false memory leak reporting when using [glib2](https://en.wikipedia.org/wiki/GLib):

    $ export G_SLICE=always-malloc G_DEBUG=gc-friendly

    Copy snippet
    Clang option to catch uninitialized memory reads: -fsanitize=memory. That option cannot be combined with -fsanitize=address.
    rpmbuild *.spec files should additionally use: -Wp,-U_FORTIFY_SOURCE.

-fsanitize is success. Would "Close with comment" except, unlike valgrind, must recompile (requires sources) to do this. What to do for executables? How to match valgrind /bin/ls without recompiling ls?

[paulfloyd]

The unrecognised instruction messages have been an issue for many years. I am under the impression that valgrind barely supports android, and I guess newer android versions might have made the situation even worse. You might have a better time using clang's memory sanitizer

Speaking as the main Valgrind contributor these days the problem is that we don't have enough developers. IBM/RedHat contributes a fair bit (good news if you are using an s390 mainframe).

In this case it's an arm64 issue, not specific to Android. I've only recently started trying to catch up with unsupported arm64 opcodes. It's still going to take me a while to get to this.