Package: xvfb
Version: 2:21.1.13-2
Severity: important
In current unstable, when xvfb-run runs Xvfb, it repeatably crashes in
libunwind on some armhf machines and with some command-line options:
see #1082659. This appears to be a regression with the recent libunwind
1.7.x upload, and is reproducible in an armhf sid chroot on the porterbox
amdahl.
For whatever reason, it seems that `xvfb-run -a -s "-noreset" true`
crashes, but `xvfb-run -a -s "-screen 0 1280x1024x24 -noreset" true`
does not.
As far as I can tell from the source code, the use of libunwind is
optional and not necessary for normal X server functionality: its only
purpose seems to be to print better backtraces if the X server crashes,
and it isn't enabled on every architecture (for example s390x and riscv64
don't build-depend on it). This makes it somewhat ironic that initializing
libunwind is, itself, causing a crash. I think crash dump analysis
frameworks like systemd-coredump, corekeeper and apport are likely to be
a better way to get information out of X server crashes.
Until libunwind can be investigated and fixed (presumably by a porter?),
I think it would be better to disable this optional feature on armhf,
so that X11-related packages can rely on being able to use Xvfb to run
their test suites on buildds.
Thanks,
smcv
