[Webkit-unassigned] [Bug 261093] New: [GTK] Race condition when reading the display number from Xvfb

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=261093

            Bug ID: 261093
           Summary: [GTK] Race condition when reading the display number
                    from Xvfb
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: bugs-noreply at webkitgtk.org

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230904/22d0368e/attachment.htm>