Bug 108635

Summary: Mesa master commit 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault
Product: Wayland Reporter: Kyle De'Vir <kyle.devir>
Component: XWaylandAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: medium CC: emil.l.velikov, lemody, lyude, Mathias.Froehlich
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=108617
Whiteboard:
i915 platform: i915 features:

Description Kyle De'Vir 2018-11-02 10:54:03 UTC
Previous commit 9cbdcc86b7209d0022ca9c31668c4d38a9598e4b is the one last working.

The segfault is simply cut off, but I'll see if I can get something useful...
Comment 1 Kyle De'Vir 2018-11-02 11:02:06 UTC
I don't know how to collect meaningful debug output from a crashing startplasmacompositor... :/

Actually, come to think of it, it's kwin_wayland that's dying, I suppose.

Not that this helps me or you devs, much. :(
Comment 2 Kyle De'Vir 2018-11-02 11:13:12 UTC
Narrowed it down to XWayland.

Seems like it doesn't like that order swap...
Comment 3 Tapani Pälli 2018-11-02 11:39:51 UTC
Since this commit fixed failing dEQP and Piglit tests I'm assuming there is something wrong in either kwin or XWayland. Perhaps with this commit it starts to actually utilize EGL_EXT_device_{base,enumeration,query} but fails.
Comment 4 Kyle De'Vir 2018-11-02 12:59:18 UTC
Hmmm.

I'll post this on the KDE side and see what they think.
Comment 5 Kyle De'Vir 2018-11-02 13:17:27 UTC
On a whim, I tried to start Sway, but XWayland also fails to start...
Comment 7 Michel Dänzer 2018-11-02 14:30:27 UTC
Adding Lyude, who wrote the Xwayland code using eglQueryDevicesEXT and eglQueryDeviceStringEXT.
Comment 8 Mathias Fröhlich 2018-11-02 14:34:00 UTC
Puh, I think that is because of the binary search implementation being the same
locale dependent than the sort that got fixed yesterday. The strcmp function used as bsearch compare uses the locale.
I will take care for a patch.

Mathias
Comment 9 Emil Velikov 2018-11-02 15:06:09 UTC
According to the man page bsearch doesn't care about the locale.

If some implementation of the C runtime does depend on it, I'm leaning towards open-coding the bsearch. It's the same amount of code.
Comment 10 Mathias Fröhlich 2018-11-02 15:36:56 UTC
Ok, strcmp does not use the locale. It would have been strcoll.
So forget about my comment.

... means needs deeper investigation.

Mathias
Comment 11 Chris Wilson 2018-11-02 15:48:53 UTC
diff --git a/src/egl/egl-entrypoint-check b/src/egl/egl-entrypoint-check
index d6a42722a44..c7f3933a29b 100755
--- a/src/egl/egl-entrypoint-check
+++ b/src/egl/egl-entrypoint-check
@@ -7,5 +7,5 @@ then
 fi
 
 entrypoints=$(grep EGL_ENTRYPOINT "$srcdir"/main/eglentrypoint.h)
-sorted=$(LC_ALL=C sort <<< "$entrypoints")
+sorted=$(LC_ALL="" sort <<< "$entrypoints")
 test "$entrypoints" = "$sorted"
Comment 12 Emil Velikov 2018-11-02 16:08:21 UTC
Neither of locale, bsearch or strcmp has anything to do here.
I'm working on fix and will send it out in a bit.
Comment 13 Emil Velikov 2018-11-02 19:09:30 UTC
Kyle can you try the following. There should be copy of it in your inbox.

https://patchwork.freedesktop.org/patch/260080/
Comment 14 Haxk20 2018-11-02 23:40:58 UTC
(In reply to Emil Velikov from comment #13)
> Kyle can you try the following. There should be copy of it in your inbox.
> 
> https://patchwork.freedesktop.org/patch/260080/

Can confirm that this patch worked for me.
Comment 15 Emil Velikov 2018-11-05 20:56:27 UTC
Thanks for the report and check everyone. I've reproduced a crash locally where this fixes it. Kyle feel free to reopen the problem persists with the below commit.

commit b3ade6538798ad9bf397d8b386eab3dd8af57f3d
Author: Emil Velikov <emil.velikov@collabora.com>
Date:   Fri Nov 2 18:34:19 2018 +0000

    egl/glvnd: correctly report errors when vendor cannot be found

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.