ivosh / valgrind

Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools.
GNU General Public License v2.0
6 stars 0 forks source link

Android OS (Termux) _a.cxx_=`int main(int, const char **) {return 0;}`, `clang++ a.cxx`, `valgrind ./a.out` gives `Unrecognised instruction at address X` #2

Open SwuduSusuwu opened 3 months ago

SwuduSusuwu commented 3 months ago

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
~ $
SwuduSusuwu commented 3 months ago
~ $ 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
~ $
SwuduSusuwu commented 3 months ago

From cxx/ClassCns.cxx:posixExec

const int posixExec(const std::string &executable, const std::string &argsS, const std::string &envVarsS) {
#ifdef _POSIX_VERSION
    char *args[] = {
        const_cast<char *>(executable.c_str()),
        const_cast<char *>(argsS.c_str()),
        NULL
    };
    char *envVars[] = {
        const_cast<char *>(envVarsS.c_str()),
        NULL
    };
    return execve(args[0], args, envVars);
#endif /* def _POSIX_VERSION */
}

, to

const int posixExec(const std::string &executable, const std::string &argsS, const std::string &envVarsS) {
}

, fixes conversationCnsTestsThrows() + testsHarnesses():

~/SubStack $ ./make.sh
/* Dual licenses: choose "Creative Commons" or "Apache 2" (allows all uses) */
/data/data/com.termux/files/usr/bin/ctags
/data/data/com.termux/files/usr/bin/clang++
./~/SubStack $ ./a.out
cxx/Macros.hxx: pass
cxx/VirusAnalysis.hxx: pass
cxx/ConversationCns.hxx: pass
~/SubStack $

, but posixExec() is supposed to exist, so can not commit this.

ivosh commented 3 months ago

Dear @SwuduSusuwu please report the bug against the official Valgrind source code: https://valgrind.org/support/bug_reports.html

This repository (https://github.com/ivosh/valgrind/) is just a fork, several years old now.