[Pkg-libvirt-maintainers] Bug#909417: gtk-vnc: FTBFS randomly (vncconnectiontest fails with "assertion failed")
Steinar H. Gunderson
sesse at debian.org
Wed Mar 20 23:33:58 GMT 2019
On Sat, Mar 09, 2019 at 07:26:52PM +0100, Santiago Vila wrote:
> Whoever wants to reproduce this (and possibly debug it), *please*
> contact me privately and I will gladly provide ssh access to a machine
> where it happens very often.
I've looked briefly into this.
First, to reproduce this reliably, simply restrict it to one core
(taskset -c 0 /build/gtk3/src/vncconnectiontest). The reason will be fairly
clear from the text below.
As far as I can see, this test simulates a broken VNC server (to test the
client's robustness). It says it's got a 100x100 true color display, but then
goes on and starts sending a color map.
As soon as the client receives the information about the color map,
it realizes something is wrong, and a race starts. Now the client wants to
close the connection at the same time as the fake server wants to keep
sending the cmap data. If you've got two cores, the server just keeps on
sending data happily; by the time it's noticed that the client is gone,
the test has passed and all is fine. But if you've only got one, then the
first byte of the cmap causes a context switch over to the client, which then
gets ample time to read the data and close the socket before the server gets
to send the next byte. The server thus gets EPIPE, and test_send_u16()
I believe the right fix is to send every byte after the first “set color map”
byte using a non-asserting send. When we've done something invalid, we'd
better be ready for sending data to fail.
Please try the attached diff; it fixes the problem for me. I can NMU if the
/* Steinar */
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1927 bytes
Desc: not available
More information about the Pkg-libvirt-maintainers