The Xvfb driver for running layout tests with the GTK port starts the Xvfb server passing the parameter `-displayfd $fd` and then waits for Xvfb to write there the display number and closes the $fd pipe. The problem is that the Xvfb program does not write the number in an atomic way. It first writes the number itself and then it writes later the \n character. See: os/connection.c-void os/connection.c-NotifyParentProcess(void) os/connection.c-{ os/connection.c-#if !defined(WIN32) os/connection.c: if (displayfd >= 0) { os/connection.c: if (write(displayfd, display, strlen(display)) != strlen(display)) os/connection.c: FatalError("Cannot write display number to fd %d\n", displayfd); os/connection.c: if (write(displayfd, "\n", 1) != 1) os/connection.c: FatalError("Cannot write display number to fd %d\n", displayfd); os/connection.c: close(displayfd); os/connection.c: displayfd = -1; os/connection.c- } So it happens that we end in a race condition sometimes where we read the number from the first write and then we close the displayfd descriptor before Xvfb had wrote the \n character and that causes Xvfb to crash or to exit with an error. Example: Fatal server error: (EE) Cannot write display number to fd 13 (EE) Xvfb crashed [pid=18829] This issue is causing sometimes unexpected crashes on the layout tests