Bug#1064021: gss: FTBFS on armhf: FAIL: krb5context

[Simon Josefsson]

Sebastian Ramacher <sramacher@debian.org> writes:

> FAIL: krb5context
> =================
>
> ==31890== 
> ==31890== Process terminating with default action of signal 11 (SIGSEGV)
> ==31890==  Access not within mapped region at address 0xBDB33984
> ==31890==    at 0x4856C00: shishi_key_parse (in 
> /usr/lib/arm-linux-gnueabihf/libshishi.so.0.1.3)
> ==31890==  If you believe this happened as a result of a stack
> ==31890==  overflow in your program's main thread (unlikely but
> ==31890==  possible), you can try to increase the size of the
> ==31890==  main thread stack using the --main-stacksize= flag.
> ==31890==  The main thread stack size used in this run was 8388608.
> FAIL krb5context (exit status: 139)

Thanks for the report.  Could this be another arch-specific valgrind
behaviour change causing FTBFS?

It seems that at some point valgrind on armhf did not raise this error
message, so building gss worked fine.  Then valgrind on armhf changed
that lead to the error message above when building the old gss.

You use valgrind version 1:3.20.0-2.1 and the last successful build of
gss used valgrind version 1:3.18.1-1.1 see log:

https://buildd.debian.org/status/fetch.php?pkg=gss&arch=armhf&ver=1.0.4-1&stamp=1659802402&raw=0

Given that gss builds use valgrind on other architectures successfully,
and has succeeded on this architecture before, I don't feel convinced
that valgrind has found a genuine gss/shishi problem here.  So I think
this bug can be reassigned to valgrind for analysis.

Some possible relevant links:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057693
https://tracker.debian.org/news/1482474/accepted-valgrind-13200-2-source-into-unstable/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224

Maybe valgrind should do a debci/autopkgtest test run on new valgrind on
gss or gsasl which has triggered similar bugs before?

/Simon

signature.asc
Description: PGP signature