Am 26.06.24 um 13:33 schrieb Jeroen Ploemen:
On Mon, 24 Jun 2024 15:28:58 +0200
Bernhard Übelacker <bernha...@mailbox.org> wrote:
There was a patch pushed to git [3] which explicitly lists valgrind
archs. I stepped over a package valgrind-if-available [4].
Maybe depending on this might be of some help here?
Thanks for the hint about valgrind-if-available. I added a commit to
use that instead of the direct dependency on valgrind + hardcoded
archs, and modified the autopkgtest script to check for the presence
of valgrind to decide whether or not to pass the -m argument.
That still leaves open how to proceed with the issue at hand.
Bernhard's debugging results point to valgrind as the root cause
rather than gpscorrelate itself. I'm tempted to do a fresh upload of
the latter with valgrind removed from the tests entirely for the time
being, and then either close or reassign this bug. Any objections?
Just to exclude an issue with qemu's arm64 emulation I tested also with
real hardware inside an unstable chroot on top of a RPi3 running Debian
Bookworm.
And received the same results - with plain gdb 323, and with valgrind 322.
I asked here at debian-...@lists.debian.org, if someone knows something [1].
But I guess for gpscorrelate it might be enough to use a workaround for now.
Kind regards,
Bernhard
[1] https://lists.debian.org/debian-arm/2024/06/msg00011.html
