Summary: | kscreenlocker_g crashes with SIGABRT, continually dumps core | ||
---|---|---|---|
Product: | [Unmaintained] kscreenlocker | Reporter: | Robert Munteanu <robert.munteanu> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | bshah, mgraesslin |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Robert Munteanu
2015-12-17 12:48:53 UTC
are all backtraces like that? Question is whether the first crash looks the same, because "QXcbConnection: Could not connect to display" doesn't make any sense. Why should it not be able to connect to the XDisplay? Unrelated to that: you should never get more than 4 crashers and afterwards an error message should be shown telling you how to unlock the screen. On second thought: that might be new in 5.5 > Question is whether the first crash looks the same Yes, I just checked the first one for today and it has the same message. > Unrelated to that: you should never get more than 4 crashers and afterwards an error message should be shown telling you how to unlock the screen. On second thought: that might be new in 5.5 It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today > It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today
sorry about that :-( Positive: it shows that the investment in ensuring that doesn't happen was worth the effort.
Could you please try to manually start
/usr/lib64/libexec/kscreenlocker_greet --testing
The question for me is whether that will also abort.
(In reply to Martin Gräßlin from comment #3) > > It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today > > sorry about that :-( Positive: it shows that the investment in ensuring that > doesn't happen was worth the effort. > > Could you please try to manually start > /usr/lib64/libexec/kscreenlocker_greet --testing > > The question for me is whether that will also abort. I will try do that. However I need to wait for the crash to happen again, and then I'll only be able to run this from another VT. No need to wait for the crash to happen again. Just run it from a konsole in your X session. (In reply to Martin Gräßlin from comment #5) > No need to wait for the crash to happen again. Just run it from a konsole in > your X session. Yes, it worked. However, locking the screen also worked fine after the last restart. all right. I set to UPSTREAM as the crash happened deep down in Qt's interaction with XCB. There is not much we can do about that anyway. Feel free to add any new information you find. E.g. if it happens again and you notice a pattern. At the moment I assume that the problem was rather in X, like X session closing or not reacting on the socket. For the record, when this problem happens I can work around it by manually killing another kscreenlocker-related process. I forgot its name, something related to 'backend' I think. So this might be a clue - that process might be holding on to a stale reference ( of something, I have no idea about X internals ) and killing it ( and probably it being restarted ) make the problem go away. > I forgot its name, something related to 'backend' I think. kscreen_backend_launcher? > So this might be a clue - that process might be holding on to a stale reference Maybe it's holding an XServerGrab. (In reply to Martin Gräßlin from comment #9) > > I forgot its name, something related to 'backend' I think. > > kscreen_backend_launcher? Yes, I think so. |