On 13/12/2024 16:26, Simon Sobisch wrote:
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.
This does look like https://bugs.kde.org/show_bug.cgi?id=327427
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: ???
Unfortunately Valgrind has failed to read its own debuginfo, so this not
much use to us.
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.
--keep-debuginfo, IIRC, is only related to keeping debuginfo for shared
libraries that get loaded and unoaded.
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
You need to analyze them.
in C posix functions from the binary
/apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I
_guess_ is not related to this error.
That could be due to Valgrind not redirecting those functions.
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...
Sorry, but we don't have anyone that uses Android working on Valgrind as
far as I know. Not much has been done that is Android specific for quite
a while. aarch64 is getting some fixes and enhancements.
A+
Paul
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
