[PATCH xserver] xwayland: avoid a crash with empty window pixmaps

[Olivier Fourdan]

Hi Daniel,

On Tue, Jan 23, 2018 at 11:15 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> Ooh. serialNumber == 1 means it's the root pixmap, which will actually
> be uselessly empty. It would be interesting to see how we've ended up
> here: it would have to be a top-level window which a) was manually
> redirected by the WM when it was created, b) had damage posted on it,
> and c) was unredirected (in that order). I can't think of how that
> would happen; maybe you could place logs for the triggers (e.g.
> removing the last manual redirect on a window) somewhere?
>

Unfortunately I don't know how to reproduce that one, all I have is a
couple of core files...

But yes, that window is a toplevel window (hexchat):

Walking down the properties list until we get to the WM_CLASS, it gives
“hexchat”.

(gdb) x /s
xwl_window->window->optional->userProps->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->data
0x215bcf0:    "hexchat"

with

(gdb) p
nodeTable[xwl_window->window->optional->userProps->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->next->propertyName]->string
$1 = 0x5b2c2c "WM_CLASS"

But the theory of the toplevel being created → redirected → damaged →
unredirected is plausible because I suspect this happens concurrently with
a crash in the Wayland compositor (gnome-shell) at startup while the apps
are restored via x-session management (from what I understood from the
issue).

(which, if my understanding is correct, means that the user session is
doomed anyway, so this crash in Xwayland might not be the culprit, but
still, I'd rather have Xwayland end with a “failed to read Wayland events”
rather than a segfault)

It would be good to see what the WindowRec under xwl_window looks
> like; maybe that could offer us a clue.
>

The xwl_window->window gives:

(gdb) p *xwl_window->window $2 = {drawable = {type = 0 '\000',
                   class = 1 '\001',
                   depth = 24 '\030',
                   bitsPerPixel = 32 ' ',
                   id = 27262979,
                   x = 3407,
                   y = 574,
                   width = 665,
                   height = 400,
                   pScreen = 0x161d200,
                   serialNumber = 11075},
       devPrivates = 0x215b998,
       parent = 0x1e5bff0,
       nextSib = 0x230c490,
       prevSib = 0x0,
       firstChild = 0x215bd60,
       lastChild = 0x215bd60,
       clipList = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0},
                   data = 0x8137a0 <RegionEmptyData>},
       borderClip = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0},
                     data = 0x8137a0 <RegionEmptyData>},
       valdata = 0x0,
       winSize = {extents = {x1 = 3407, y1 = 574, x2 = 4072, y2 = 974},
                  data = 0x0},
       borderSize = {extents = {x1 = 3407, y1 = 574, x2 = 4072, y2 = 974},
                     data = 0x0},
       origin = {x = 3407, y = 574},
       borderWidth = 0,
       deliverableEvents = 32895,
       eventMask = 6520959,
       background = {pixmap = 0xe8e8e7, pixel = 15263975},
       border = {pixmap = 0x0, pixel = 0},
       optional = 0x215bb10,
       backgroundState = 2,
       borderIsPixel = 1,
       cursorIsNone = 1,
       backingStore = 0,
       backStorage = 0,
       saveUnder = 0,
       bitGravity = 1,
       winGravity = 1,
       overrideRedirect = 0,
       visibility = 2, (VisibilityFullyObscured)
       mapped = 1,
       realized = 1,
       viewable = 1,
       dontPropagate = 0,
       forcedBS = 0,
       redirectDraw = 0,
       forcedBG = 0,
       unhittable = 0,
       damagedDescendants = 0,
       inhibitBGPaint = 0}

I didn't spot anything suspicious about it.

Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180123/6065d53a/attachment.html>