El 2/2/25 a las 17:43, Ole Streicher escribió:
What happens is that xfvb-run does not really wait until the X server is able
to be connected. From its sources:
wait || :
if kill -0 $XVFBPID 2>/dev/null; then
break
Good work!
which means that it just waits until the X server can answer a signal, which
may be too early. So, the XOpenDisplay() in test-cairo-xw.c
will fail and return NULL, which is then taken unconditionally used as
parameter for DefaultScreen(), which then produces the segfault.
So, I think the reason is a buggy xvfb-run in combination with a slow machine.
It's not a particularly slow machine, it's a perfectly working machine which has
a 4th generation EPYC processor from AMD.
Therefore, my proposal would be to re-assign this to xvfb and lower the importance to
"important". Introducing artificial sleeps in the giza build would seem fishy
to me.
Better ideas anyone?
I would do both things: add a simple sleep in debian/rules (if that solves the
problem)
and clone (not reassign) the bug.
Then, when/if they fix the problem in xvfb the workaround could be removed, but
hopefully
not before.
(If required, I would be willing to help in any of the above, since I joined
this team
to help, and this bug is particularly annoying to me).
Thanks.
