(Slightly surprised I didn't find anything about this by searching Bugzilla, so apologies if I've overlooked an existing bug.) I get two main sorts of error: ==3230== 8 bytes in 1 blocks are definitely lost in loss record 1 of 5 ==3230== at 0x4A23B44: operator new(unsigned long) (in /data/data/com.termux/files/usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so) and: ==3374== Source and destination overlap in memcpy(0x4a20b20, 0x4a20b20, 80) ==3374== at 0x4957724: memcpy (in /data/data/com.termux/files/usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so) As you can see, I'm using valgind in Termux, and indeed with the stock Termux package, in case that helps.
I'm sorry, I think I've misunderstood the logs: it's not reporting leaks etc. in vgpreload_memcheck-arm64-linux.so, it's that I would expect a further backtrace, but there isn't anything other than the lines I showed above. Still something odd going on…
I mean, specifically, no callers are listed (no "by" lines).
That probably means you have stripped all the unwind information from vgpreload_memcheck-arm64-linux.so so valgrind is unable to unwind the stack to the next function.
As I said, it's a stock build. So looks like a problem with the Termux build, I'll investigate that. Thanks!
I've filed https://github.com/termux/termux-packages/issues/2148
(In reply to rrt from comment #5) > I've filed https://github.com/termux/termux-packages/issues/2148 Hi! I fixed some debuginfo reading stuff for arm64-linux recently (within the past month) so it might be worth you trying the git trunk, to see if this still happens.
Sorry, I didn't say that a rebuild fixed it; a Termux script (termux-elf-cleaner) used to remove some supposedly unneeded stuff from ELF binaries was found to be the culprit.