assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

Simon Sobisch <[email protected]> Fri, 13 Dec 2024 16:26:56 +0100
Newsgroups gmane.comp.debugging.valgrind
Message-ID <[email protected]>
Daear valgrind users and devs,

Valgrind-3.22.0 and asserts reproducible on 
aarch64-unknown-linux-android (with several applications) as follows:

valgrind: 
/home/builder/.termux-build/valgrind/src/coregrind/m_redir.c:796 (void 
vgPlain_redir_add_ifunc_target(Addr, Addr)): Assertion 'old' failed.

host stacktrace:
==27034==    at 0x5802EB10: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5802EE4B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5802EE27: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x58041BB3: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5809247B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x580A180B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0xFFFFFFFFFFFFFFFF: ???

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 27034)
==27034==    at 0x5DE8460: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/vgpreload_core-arm64-linux.so)
client stack range: [0x1FFEFF9000 0x1FFF000FFF] client SP: 0x1FFEFFCAC0
valgrind stack range: [0x1002CBC000 0x1002DBBFFF] top usage: 12432 of 
1048576


Following the output of the assert I've found
     https://bugs.kde.org/show_bug.cgi?id=327427
but the test w/wo --keep-debuginfos=yes / no showed the same stacktrace 
in this case.


The application does not show any errors in other environments.

In this environment we get a bunch of warnings
    Conditional jump or move depends on uninitialised value(s)
    Use of uninitialised value of size 8
in C posix functions from the binary 
/apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I 
_guess_ is not related to this error.


Is there something that's "known" which I've overlooked (FAQ has no 
entries on this, changelog from newer versions did not show anything 
that seems related)?


I've tried to build the last release but have not resolved the place why 
it tries to link against the non-existing libc and how to fix that...


Any hints on the bug issue (or the linking) welcome,
Simon