While glibc 2.27 passes its test suite in Ubuntu at build time when building on a system running an Ubuntu 4.4 Linux kernel, when the test suite is subsequently run on a test runner using a 4.15 kernel there are two test failures related to backtraces (out of 4 test failures total): FAIL: debug/tst-backtrace4 original exit status 1 Obtained backtrace with 3 functions (want at least 6) Failure on line 53 Function 0: /tmp/autopkgtest.WmumFK/build.JMe/src/build-tree/s390x-s390/debug/tst-backtrace4(handle_signal+0x2e) [0x4017fe] Function 1: [0x7fca1d4e] Function 2: [(nil)] ---------- ---------- FAIL: debug/tst-backtrace5 original exit status 1 Obtained backtrace with 3 functions Failure on line 53 ---------- ----------
Note that this is the 31-bit (ie: s390) biarch build, *not* the s390x build, as the title implies.
Also, in the "changing all the variables at once is super scientific" camp, our move from glibc 2.26 to 2.27 also involved a move from gcc-6 to gcc-7, and given the nature of these tests, it's entirely possible that's coming in to play here too.
The four failing tests (nptl/tst-cancelx20, nptl/tst-cancelx21, debug/tst-backtrace4, debug/tst-backtrace5) on s390 (31bit) are due to a kernel-bug. In all cases, showing the backtrace or unwinding is not possible beyond the signal-handler. There is a kernel-bug setting up the pointer to the stored registers. See commit from Heiko "s390/compat: fix setup_frame32" (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b09ca746a643ca452cd41a522046a96ee5a55fd).
I've just installed Ubuntu 18.04 with the kernel 4.15.0-20-generic. It seems as this kernel contains the mentioned commit as those tests are now passing on s390 (31bit). How to proceed with this bugzilla? Can we just set it to resolved?
(In reply to Stefan Liebler from comment #4) > I've just installed Ubuntu 18.04 with the kernel 4.15.0-20-generic. > It seems as this kernel contains the mentioned commit > as those tests are now passing on s390 (31bit). > > How to proceed with this bugzilla? Can we just set it to resolved? From our perspective this was never a bug, and without a properly setup signal frame there is no backtracing can work so there isn't even an easy way to workaround this in userspace. Marking RESOLVED/INVALID. Thanks for looking into this Stefan!