Sebastian Ramacher <sramac...@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