Package: libunwind8 Version: 1.3.2-2 Severity: grave Tags: upstream X-Debbugs-Cc: debian-glibc@lists.debian.org
Following the glibc 2.32 upload to unstable, the autopkgtest of the rspamd package fails on i386, due to a segmentation fault when starting the daemon [1]. After digging, it appears that the problem is due to libunwind and the following upstream glibc change [2]: | commit 15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9 (master) | Author: H.J. Lu <hjl.to...@gmail.com> | Date: Sat Feb 1 05:44:55 2020 -0800 | | i386: Don't unnecessarily save and restore EAX, ECX and EDX [BZ# 25262] | | On i386, since EAX, ECX and EDX are caller-saved, there are no need | to save and restore EAX, ECX and EDX in getcontext, setcontext and | swapcontext. They just need to clear EAX on success. The extra | scratch registers are needed to enable CET. | | Tested on i386. | | Reviewed-by: Adhemerval Zanella <adhemerval.zane...@linaro.org> Basically EAX, ECX and EDX and are not saved anymore across a getcontext() / setcontext() sequence, and more importantly they are not restored in setcontext() which is used by libunwind to restore a context after an exception. In that case, all the registers have to be restored, including the caller-saved one. It happens that libunwind shall not have used setcontext() there, but rather defined its own implementation like its already done for getcontext() as the behaviour of setcontext() is unspecified when passed an ucp argument obtained from different sources than getcontext() or makecontext(). Quoting the GNU libc manual: | If the context was created by a call to a signal handler or from any | other source then the behaviour of setcontext is unspecified. Quoting POSIX.1-2004 (last version before it got removed): | The effects of passing a ucp argument obtained from any other source | are unspecified. Note that upstream bug #69 might be relevant there [3]. [1] https://ci.debian.net/data/autopkgtest/testing/i386/r/rspamd/15290363/log.gz [2] https://sourceware.org/git/?p=glibc.git;a=commit;h=15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9 [3] https://github.com/libunwind/libunwind/issues/69
