hi Shriram,

it seems the recent upload of gpscorrelate has issues preventing
migration to testing [1]: the autopkgtest fails for all architectures
except amd64 and i386.

This could be something really simply causing the output on these
platforms to differ in some unimportant way from what the tests
expect (like the architecture getting recorded as part of the
output with upstream only taking the "standard" archs into account),
or something more substantial (actual bugs only triggered on these
"other" archs).

Some archs have 30 tests failing (s390x), some only one (arm64); and
then there's valgrind that is not available on some architectures. I
already pushed a fix for the valgrind part to git.

Please investigate the failures on the archs where the autopkgtest
did run.


[1]https://qa.debian.org/excuses.php?package=gpscorrelate

Hi Jeroen,

I ran the tests on an arm64 machine,

This is the diff of the test that fails:

*** Running "Correlate a file with heading with delta crossing 360 degrees CCW" test
+ valgrind --error-exitcode=126 --tool=memcheck --leak-check=yes --num-callers=30 --log-file=/tmp/gpscorrelate/gpscorrelate/tests/log/test167-valgrind.log /usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g /tmp/gpscorrelate/gpscorrelate/tests/staging/track13.gpx /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg
+ exiv2 -pv pr /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg
+ EXITCODE=0
+ set +x
Test test167 FAILED: unexpected output
--- /tmp/gpscorrelate/gpscorrelate/tests/data/test167.result    2024-05-23 15:44:05.115054075 +0000
+++ /tmp/gpscorrelate/gpscorrelate/tests/log/test167.out        2024-05-23 16:49:30.700053733 +0000
@@ -32,6 +32,6 @@
  0x0006 GPSInfo      GPSAltitude                 Rational    1  4234/10
  0x0007 GPSInfo      GPSTimeStamp                Rational    3  12/1 34/1 35/1
  0x000e GPSInfo      GPSTrackRef                 Ascii       2  T
-0x000f GPSInfo      GPSTrack                    Rational    1  323/1
+0x000f GPSInfo      GPSTrack                    Rational    1  322/1
  0x0012 GPSInfo      GPSMapDatum                 Ascii       7  WGS-84
  0x001d GPSInfo      GPSDateStamp                Ascii      11  2012:11:22

I am not entirely sure why it outputs 322/1 instead of 323/1 on arm. I will reach out to the upstream maintainer regarding this.

Best Regards,

Hi Jeroen,

I ran the tests on an arm64 machine,

This is the diff of the test that fails:

*** Running "Correlate a file with heading with delta crossing 360 degrees CCW" test
+ valgrind --error-exitcode=126 --tool=memcheck --leak-check=yes --num-callers=30 --log-file=/tmp/gpscorrelate/gpscorrelate/tests/log/test167-valgrind.log /usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g /tmp/gpscorrelate/gpscorrelate/tests/staging/track13.gpx /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg
+ exiv2 -pv pr /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg
+ EXITCODE=0
+ set +x
Test test167 FAILED: unexpected output
--- /tmp/gpscorrelate/gpscorrelate/tests/data/test167.result    2024-05-23 15:44:05.115054075 +0000
+++ /tmp/gpscorrelate/gpscorrelate/tests/log/test167.out        2024-05-23 16:49:30.700053733 +0000
@@ -32,6 +32,6 @@
  0x0006 GPSInfo      GPSAltitude                 Rational    1  4234/10
  0x0007 GPSInfo      GPSTimeStamp                Rational    3  12/1 34/1 35/1
  0x000e GPSInfo      GPSTrackRef                 Ascii       2  T
-0x000f GPSInfo      GPSTrack                    Rational    1  323/1
+0x000f GPSInfo      GPSTrack                    Rational    1  322/1
  0x0012 GPSInfo      GPSMapDatum                 Ascii       7  WGS-84
  0x001d GPSInfo      GPSDateStamp                Ascii      11  2012:11:22

I am not entirely sure why it outputs 322/1 instead of 323/1 on arm. I will reach out to the upstream maintainer regarding this.

Best Regards,

I tried to collect some more informations about this issue.
I could reproduce it inside a Unstable qemu arm64 VM
(running on amd64 hardware).


First it looks like the package build never uses valgrind (-m) [1],
therefore this issue appears just in the autopkgtest, as this always
uses the (-m) [2]. Cannot say if this intentional.

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?


And the issue itself manifests at arm64 in following instruction
with the same input producing a result in register $w5 of
- without valgrind 323,
- with valgrind  322

     <ConvertToRational+104>:   fcvtas  w5, d8

Unfortunately I don't know why this happens, maybe some
floating point initialisation is done in valgrind?

See attached file for complete gdb sessions without and with valgrind.
At the bottom is also a minimal reproducer which showed the difference
with and without valgrind to me.


Kind regards,
Bernhard


[1]
./Makefile:13:CHECK_OPTIONS=
./Makefile-60-check: gpscorrelate$(EXEEXT)
./Makefile:61:  (cd tests && ./testsuite $(CHECK_OPTIONS))

[2]
./debian/tests/upstream-suite:14:./testsuite -m

[3]
https://salsa.debian.org/debian/gpscorrelate/-/commit/818f924c401fcaac4873ff3acb99b614065afc10

[4]
https://packages.debian.org/sid/valgrind-if-available

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?

Am 26.06.24 um 13:33 schrieb Jeroen Ploemen:

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-arm@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

Sorry, I copied a slightly wrong version of the minimal reproducer
in the attachement of my first message,
which unfortunately uses not a fcvtas instruction.
(It is sensitive to the optimization level.)

The intended minimal reproducer is below.

Kind regards,
Bernhard





benutzer@chroot-13-trixie-unstable:~$ cat fp-valgrind-test.c
/*
cat fp-valgrind-test.c
gcc -g -O2 fp-valgrind-test.c -o fp-valgrind-test -lm
./fp-valgrind-test
valgrind ./fp-valgrind-test
gdb -q --args ./fp-valgrind-test
disassemble main
q
*/

#include <stdio.h>
#include <math.h>

double __attribute__((optimize("O0"))) value()
{
   return 322.5;
}

int main()
{
   double a = value();
   int b = (int)round(a);
   printf("a=%f a=0x%llx b=%d\n", a, *(long long unsigned int*)&a, b);
}
benutzer@chroot-13-trixie-unstable:~$ gcc -g -O2 fp-valgrind-test.c -o fp-valgrind-test -lm
benutzer@chroot-13-trixie-unstable:~$ ./fp-valgrind-test
a=322.500000 a=0x4074280000000000 b=323
benutzer@chroot-13-trixie-unstable:~$ valgrind ./fp-valgrind-test
==26860== Memcheck, a memory error detector
==26860== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==26860== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==26860== Command: ./fp-valgrind-test
==26860==
a=322.500000 a=0x4074280000000000 b=322
==26860==
==26860== HEAP SUMMARY:
==26860==     in use at exit: 0 bytes in 0 blocks
==26860==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==26860==
==26860== All heap blocks were freed -- no leaks are possible
==26860==
==26860== For lists of detected and suppressed errors, rerun with: -s
==26860== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
benutzer@chroot-13-trixie-unstable:~$ gdb -q --args ./fp-valgrind-test
Reading symbols from ./fp-valgrind-test...
(gdb) disassemble main
Dump of assembler code for function main:
    0x0000000000000640 <+0>:     stp     x29, x30, [sp, #-16]!
    0x0000000000000644 <+4>:     mov     x29, sp
    0x0000000000000648 <+8>:     bl      0x7a0 <value>
    0x000000000000064c <+12>:    fcvtas  w2, d0                                 <<<<<<< in valgrind $w0 is 322, without valgrind $w0 is 323
    0x0000000000000650 <+16>:    fmov    x1, d0
    0x0000000000000654 <+20>:    adrp    x0, 0x0
    0x0000000000000658 <+24>:    add     x0, x0, #0x7d0
    0x000000000000065c <+28>:    bl      0x630 <printf@plt>
    0x0000000000000660 <+32>:    mov     w0, #0x0                        // #0
    0x0000000000000664 <+36>:    ldp     x29, x30, [sp], #16
    0x0000000000000668 <+40>:    ret
End of assembler dump.
(gdb) q
benutzer@chroot-13-trixie-unstable:~$

Which led to the assumption this is just a "regular" valgrind bug.

I opened following upstream bug.
Attached also a patch to valgrind.

https://bugs.kde.org/show_bug.cgi?id=489338