Bug 1318541 - kde (e.g kscreenlocker) crashes in driDestroyScreen/llvmpipe_destroy_screen/pthread_barrier_destroy
Summary: kde (e.g kscreenlocker) crashes in driDestroyScreen/llvmpipe_destroy_screen/p...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 24
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 1299167 1302423 1319321 1319722 (view as bug list)
Depends On:
Blocks: F24AlphaFreezeException
TreeView+ depends on / blocked
 
Reported: 2016-03-17 07:58 UTC by Adam Williamson
Modified: 2016-03-28 19:30 UTC (History)
15 users (show)

Fixed In Version: mesa-11.2.0-0.devel.12.24ea81a.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-23 15:17:31 UTC
Type: Bug


Attachments (Terms of Use)
kscreenlocker_greet crash backtrace (13.32 KB, text/plain)
2016-03-18 04:48 UTC, Adam Williamson
no flags Details
screenshot of sddm segfault with vga/vnc graphics (47.57 KB, image/png)
2016-03-18 19:57 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2016-03-17 07:58:47 UTC
I installed Fedora 24 Alpha 1.5 KDE x86_64 live: https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160316.3/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-24_Alpha-5.iso . It installed fine, I was able to create a user in initial-setup and log in. I then left the VM running. After a while the session auto-locked. When I tried to unlock it, I could not. If I enter an invalid password and click Unlock, I see an "Unlocking failed" error message, OK. If I enter the correct password and click Unlock, the screen goes blank briefly then cycles back to the lock screen. If I do this several times, instead of going back to the lock screen, I see an error in large white type on a black background, slightly cut off at the edges:

(?)creen locker is broken and unlocking is not possible any(?)
(?)rder to unlock switch to a virtual terminal (e.g. Ctrl+Alt+(?)
log in and execute the command:
loginctl unlock-sessions
(?)terwards switch back to the running session (Ctrl+Alt+F(?)

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

Comment 1 Adam Williamson 2016-03-17 08:00:00 UTC
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).

Comment 2 Adam Williamson 2016-03-18 00:59:10 UTC
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?)

Comment 3 Adam Williamson 2016-03-18 04:48:00 UTC
Created attachment 1137667 [details]
kscreenlocker_greet crash backtrace

Generated manually with gdb.

Comment 4 Rex Dieter 2016-03-18 13:12:16 UTC
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>

Comment 5 Adam Williamson 2016-03-18 14:41:22 UTC
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.

Comment 6 Adam Williamson 2016-03-18 14:50:09 UTC
CCing the usual graphics suspects for now.

Comment 7 Adam Williamson 2016-03-18 19:51:53 UTC
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.

Comment 8 Adam Williamson 2016-03-18 19:57:14 UTC
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.

Comment 9 Adam Williamson 2016-03-18 19:57:49 UTC
Created attachment 1137863 [details]
screenshot of sddm segfault with vga/vnc graphics

Comment 10 Adam Williamson 2016-03-18 21:18:07 UTC
KVM with the graphics set to vmvga / VNC shows the same problem as qxl / SPICE, kscreenlocker_greet crashes.

Comment 11 Rex Dieter 2016-03-21 12:29:21 UTC
updating summary (for incoming dups)

Comment 12 Rex Dieter 2016-03-21 12:30:38 UTC
*** Bug 1319722 has been marked as a duplicate of this bug. ***

Comment 13 Rex Dieter 2016-03-21 12:37:29 UTC
*** Bug 1319321 has been marked as a duplicate of this bug. ***

Comment 14 Rex Dieter 2016-03-21 12:38:56 UTC
*** Bug 1302423 has been marked as a duplicate of this bug. ***

Comment 15 Rex Dieter 2016-03-21 12:40:19 UTC
*** Bug 1299167 has been marked as a duplicate of this bug. ***

Comment 16 Michael Catanzaro 2016-03-21 15:06:07 UTC
(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.)

Comment 17 Kamil Páral 2016-03-21 16:48:28 UTC
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

Comment 18 Fedora Update System 2016-03-21 19:11:18 UTC
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

Comment 19 Fedora Update System 2016-03-21 22:29:58 UTC
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

Comment 20 Adam Williamson 2016-03-23 06:02:36 UTC
Fix looks good in Alpha-1.7, thanks.

Comment 21 Fedora Update System 2016-03-23 15:17:17 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.