Valgrind does not produce backtraces

[rrthomas]

I get output from Valgrind like this:

==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)

What's missing is further lines saying which functions in my code called the Valgrind shims for new, memcpy etc.

I reported this bug to Valgrind: https://bugs.kde.org/show_bug.cgi?id=390498

And they suggested it was a problem with the build: specifically, that unwind information has been stripped from vgpreload_memcheck-arm64-linux.so.

Looking at the build.sh for valgrind, it doesn't seem to do anything non-default in this respect, so do Termux default compiler settings strip this info?

[tomhughes]

@rrthomas Does readelf -S on that library show a .eh_frame or .debug_frame section? If termux has separate debug packages then does installing the relevant debug package for valgrind help?

[rrthomas]

@tomhughes, no, it doesn't show either of those. As far as I know, termux doesn't have debug packages. (I see only a valgrind-dev package, which contains, as one would expect, development headers etc., and no libraries.)

[tomhughes]

OK. So I wouldn't expect a .debug_frame unless you're building with debug which a distro build normally wouldn't unless it was going to strip it off to a separate package.

Not having .eh_frame is odder however... Is it building with -fno-exceptions or something?

If it builds without debug or exception support, and also omits frame pointers (the default on x86_64) then there's basically no way to unwind the stack.

[Grimler91]

I tried building a debug version of valgrind but ran into

aarch64-linux-android-gcc -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector -fno-strict-aliasing -fno-builtin  -O -g -fno-omit-frame-pointer -fno-strict-aliasing -fpic -fno-builtin  -O2 -specs=/home/builder/termux-packages/termux.spec -g3 -O1 -fstack-protector --param ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst -nostdlib  -Wl,--whole-archive ../coregrind/libreplacemalloc_toolpreload-arm64-linux.a -Wl,--no-whole-archive -L/data/data/com.termux/files/usr/lib -specs=/home/builder/termux-packages/termux.spec -o vgpreload_memcheck-arm64-linux.so vgpreload_memcheck_arm64_linux_so-mc_replace_strmem.o
../coregrind/link_tool_exe_linux 0x58000000 aarch64-linux-android-gcc  -specs=/home/builder/termux-packages/termux.spec -g3 -O1 -fstack-protector --param ssp-buffer-size=4 -D_FORTIFY_SOURCE=2  -L/data/data/com.termux/files/usr/lib -specs=/home/builder/termux-packages/termux.spec -o memcheck-arm64-linux -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector -fno-strict-aliasing -fno-builtin  -O2 -static -nodefaultlibs -nostartfiles -u _start   memcheck_arm64_linux-mc_leakcheck.o memcheck_arm64_linux-mc_malloc_wrappers.o memcheck_arm64_linux-mc_main.o memcheck_arm64_linux-mc_translate.o memcheck_arm64_linux-mc_machine.o memcheck_arm64_linux-mc_errors.o ../coregrind/libcoregrind-arm64-linux.a ../VEX/libvex-arm64-linux.a -lgcc
/home/builder/.termux-build/valgrind/src/memcheck/mc_leakcheck.c:1996: error: undefined reference to '__stack_chk_guard'
/home/builder/.termux-build/valgrind/src/memcheck/mc_leakcheck.c:1996: error: undefined reference to '__stack_chk_guard'
/home/builder/.termux-build/valgrind/src/memcheck/mc_leakcheck.c:2228: error: undefined reference to '__stack_chk_guard'
/home/builder/.termux-build/valgrind/src/memcheck/mc_leakcheck.c:2228: error: undefined reference to '__stack_chk_guard'
/home/builder/.termux-build/_lib/16-aarch64-21-v3/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: internal error in maybe_apply_stub, at /usr/local/google/buildbot/src/android/gcc/toolchain/build/../binutils/binutils-2.27/gold/aarch64.cc:5449
collect2: error: ld returned 1 exit status
Makefile:1007: recipe for target 'memcheck-arm64-linux' failed
make[3]: *** [memcheck-arm64-linux] Error 1
make[3]: Leaving directory '/home/builder/.termux-build/valgrind/build/memcheck'
Makefile:1283: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/builder/.termux-build/valgrind/build/memcheck'
Makefile:829: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/builder/.termux-build/valgrind/build'
Makefile:698: recipe for target 'all' failed
make: *** [all] Error 2

Can see if I can solve that.

[tomhughes]

You won't be able to use anything like -fstack-protector that needs to link with auxilliary libraries because valgrind tools are linked in very special ways and don't pull in any libraries.

[Grimler91]

Right, thanks. Removing -fstack-protector made it build with debug symbols as it should. I uploaded the debug packages here if you want to test: https://grimler.se/dists/testing/debug/binary-aarch64/valgrind_3.13.0_aarch64.deb

I also noticed that termux-elf-cleaner removes some stuff from the library, log says termux-elf-cleaner: Replacing unsupported DF_1_* flags 1057 with 1 in ./lib/valgrind/vgpreload_memcheck-x86-linux.so'

I uploaded valgrind built without this cleaning here: https://grimler.se/dists/testing/misc/binary-aarch64/valgrind_3.13.0_aarch64.deb Please test it.

[rrthomas]

Thanks very much, that works.

[Grimler91]

@rrthomas which one? The one without termux-elf-cleaner?

[rrthomas]

Exactly. Sorry, I'm on my phone, I didn't see the first one, and I've not tried it.

[rrthomas]

Would it be useful if I tested the other one too? I am guessing no, because simply building without cleaning is lighter weight than building with debug?

[Grimler91]

@rrthomas No, it's fine, since we've established that termux-elf-cleaner is the culprit!

[rrthomas]

Great stuff, thanks!

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.