Bug 1318541

the error message's recommendation does work, FWIW (logging into a tty as root and running 'loginctl unlock-sessions' gets me back to the desktop).

Discussed at 2016-03-17 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot.fedoraproject.org/fedora-meeting/2016-03-17/f24-alpha-go_no_go-meeting.2016-03-17-17.00.html . We agreed that this looks pretty worrying, but we'd like a bit more data before making a definite decision (e.g. we should get some tracebacks, and why can I reproduce it reliably but Rex could not?)

Created attachment 1137667 [details]
kscreenlocker_greet crash backtrace

Generated manually with gdb.

To my untrained eye, this appears to be some sort of mesa/llvmpipe crash?

#1  0x00007f76d16bbc3f in KCrash::defaultCrashHandler (sig=8) at /usr/src/debug/kcrash-5.19.0/src/kcrash.cpp:431
        argv = {0x7f76d1afa880 <QQmlVMEVariantQObjectPtr::~QQmlVMEVariantQObjectPtr()> "H\215\005\361r\032", 0x0, 
          0x7ffedf04fbd0 "\320.\210\314v\177", 0x55fd3ef0b590 "J\350\257", <incomplete sequence \313>, 
          0x55fd3ef07c80 "P^\357>\375U", 0x55fd3eefb4b8 "", 0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 
          0x7f76cb7bcedc <__GI___libc_free+76> "H\203\304([]A\\A]\303f\017\037\204", 0x7f769c156ec8 "", 
          0x7f769c1909a0 " \301\022\234v\177", 0x1 <error: Cannot access memory at address 0x1>, 0x0, 
          0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 0x0, 0x7ffedf04fbd0 "\320.\210\314v\177", 0x55fd3ef0b5f0 "", 
          0x55fd3ee4fcb8 " ;p\314v\177", 0x55fd3ef0b590 "J\350\257", <incomplete sequence \313>, 
          0x55fd3ef07c80 "P^\357>\375U", 0x55fd3eefb4b8 "", 0x7f76cc882ed0 <_q_ObjectMutexPool+848> "", 
          0x7f76cb7bcedc <__GI___libc_free+76> "H\203\304([]A\\A]\303f\017\037\204", 
          0x1 <error: Cannot access memory at address 0x1>, 
          0x98ce988ae9a9a600 <error: Cannot access memory at address 0x98ce988ae9a9a600>, 0x7f769c1909a0 " \301\022\234v\177", 
          0x0, 0x55fd3ee4fcb8 " ;p\314v\177", 0x0, 0x7f769c056218 "p2\027\234v\177"}
        i = <optimized out>
        platformName = {d = 0x7f769c0f3370}
        about = <optimized out>
        sigtxt = "\001\000\000\000\000\000\000\000\000"
        pidtxt = "\320.\210\314v\177\000\000\334\316{\313v\177\000\000p\262\357>"
        startupId = {d = 0x400}
        crashRecursionCounter = 2
#2  <signal handler called>
No locals.
#3  0x00007f76ca61e789 in pthread_barrier_destroy (barrier=barrier@entry=0x55fd3ea337e0) at pthread_barrier_destroy.c:40
        bar = 0x55fd3ea337e0
        count = 0
        max_in_before_reset = <optimized out>
        in = <optimized out>
#4  0x00007f76b228a07f in pipe_barrier_destroy (barrier=0x55fd3ea337e0) at ../../../../src/gallium/auxiliary/os/os_thread.h:155
No locals.
#5  lp_rast_destroy (rast=0x55fd3ea320c0) at lp_rast.c:970
        i = 1
#6  0x00007f76b2293f71 in llvmpipe_destroy_screen (_screen=0x55fd3ea31b50) at lp_screen.c:528
        screen = 0x55fd3ea31b50
        winsys = 0x55fd3ea31af0
#7  0x00007f76b1edce7f in dri_destroy_screen_helper (screen=screen@entry=0x55fd3ea319b0) at dri_screen.c:380
No locals.
#8  0x00007f76b1edcf25 in dri_destroy_screen (sPriv=0x55fd3ea31910) at dri_screen.c:391
        screen = 0x55fd3ea319b0
#9  0x00007f76b1edb272 in driDestroyScreen (psp=0x55fd3ea31910) at dri_util.c:228
No locals.
#10 0x00007f76ca1aa1c5 in driswDestroyScreen (base=0x55fd3e9e77e0) at drisw_glx.c:587
        psc = 0x55fd3e9e77e0
#11 0x00007f76ca185f8c in FreeScreenConfigs (priv=<optimized out>, priv=<optimized out>) at glxext.c:217
        psc = 0x55fd3e9e77e0
        i = <optimized out>
        screens = <optimized out>
#12 0x00007f76ca186009 in glx_display_free (priv=priv@entry=0x55fd3e9e92d0) at glxext.c:240
        gc = <optimized out>
#13 0x00007f76ca18615e in __glXCloseDisplay (dpy=0x55fd3e9a09d0, codes=<optimized out>) at glxext.c:288
        priv = 0x55fd3e9e92d0
        prev = <optimized out>
#14 0x00007f76d3041a42 in XCloseDisplay (dpy=0x55fd3e9a09d0) at ClDisplay.c:65
        ext = 0x55fd3e9e9350
        i = <optimized out>

Believe me, your eye is more trained than mine when it comes to C backtraces...

that would explain why you couldn't reproduce on bare metal too, I guess? I'll try with bare metal and a few variations on video config in the KVM today.

CCing the usual graphics suspects for now.

OK yeah, so confirmed that it works for me on bare metal (Intel graphics). Let's tentatively assign this to mesa for now, I'll try and narrow it down a bit more.

I tried testing a VM with graphics set to vga / VNC; it doesn't even make it to the desktop. Booting with 'quiet' removed shows sddm segfaulting with a general protection fault in Qt, will attach a screenshot.

Created attachment 1137863 [details]
screenshot of sddm segfault with vga/vnc graphics

KVM with the graphics set to vmvga / VNC shows the same problem as qxl / SPICE, kscreenlocker_greet crashes.

updating summary (for incoming dups)

*** Bug 1319722 has been marked as a duplicate of this bug. ***

*** Bug 1319321 has been marked as a duplicate of this bug. ***

*** Bug 1302423 has been marked as a duplicate of this bug. ***

*** Bug 1299167 has been marked as a duplicate of this bug. ***

(In reply to Adam Williamson from comment #0)
> Proposing as an Alpha blocker - I'm gonna cite "A system installed with a
> release-blocking desktop must boot to a log in screen where it is possible
> to log in to a working desktop using a user account created during
> installation or a 'first boot' utility.", on the basis that the 'working'
> desktop becomes 'not working' rather easily just by being left alone for a
> few minutes.
> https://fedoraproject.org/wiki/
> Fedora_24_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

Personally, I think this is a little iffy; I don't think it's so horrible if the alpha release doesn't work after a screen lock. (But I agree it should be a blocker for the final release.)

Discussed at today's blocker review meeting [1]. Voted as RejectedBlocker AcceptedFreezeException (Alpha) - it's a close call, but we feel the overall impact of this conditional violation is not quite sufficient enough to constitute an Alpha blocker. It's clearly worth a freeze exception, however

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-21

mesa-11.2.0-0.devel.12.24ea81a.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e27c369d3

mesa-11.2.0-0.devel.12.24ea81a.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8e27c369d3

Fix looks good in Alpha-1.7, thanks.

mesa-11.2.0-0.devel.12.24ea81a.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.