Bug 337781

Summary: Crash in KF5 with kwin_x11 --replace ( xcb )
Product: [Plasma] kwin Reporter: Nicolas L. <kde>
Component: coreAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: major CC: hrvoje.senjan
Priority: NOR    
Version: 5.0.0   
Target Milestone: ---   
Platform: Mageia RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: here is the log.
new conf file

Description Nicolas L. 2014-07-24 21:35:05 UTC
#0  0x0000003b7200ee70 in xcb_setup_vendor_end (R=R@entry=0x0) at xproto.c:1569
#1  0x0000003b7200eec9 in xcb_setup_pixmap_formats_iterator (R=R@entry=0x0) at xproto.c:1622
#2  0x0000003b7200ef09 in xcb_setup_roots_iterator (R=0x0) at xproto.c:1659
#3  0x0000003b8c4490ff in KWin::ColorMapper::ColorMapper(QObject*) () at /usr/src/debug/kwin-5.0.0/libkwineffects/kwinglobals.h:171
#4  0x0000003b8c4490ff in KWin::ColorMapper::ColorMapper(QObject*) (this=this@entry=0x6a6560, parent=parent@entry=0x6a7250) at /usr/src/debug/kwin-5.0.0/workspace.cpp:84
#5  0x0000003b8c4508b9 in KWin::Workspace::Workspace(bool) (this=0x6a7250, restore=<optimized out>) at /usr/src/debug/kwin-5.0.0/workspace.cpp:175
#6  0x0000003b8c48086c in QtPrivate::QFunctorSlotObject<KWin::Application::start()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (__closure=<synthetic pointer>) at /usr/src/debug/kwin-5.0.0/main.cpp:271
#7  0x0000003b8c48086c in QtPrivate::QFunctorSlotObject<KWin::Application::start()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (arg=<optimized out>, f=...) at /usr/lib64/qt5/include/QtCore/qobjectdefs_impl.h:502
#8  0x0000003b8c48086c in QtPrivate::QFunctorSlotObject<KWin::Application::start()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (arg=<optimized out>, f=...) at /usr/lib64/qt5/include/QtCore/qobjectdefs_impl.h:559
#9  0x0000003b8c48086c in QtPrivate::QFunctorSlotObject<KWin::Application::start()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=<optimized out>, this_=<optimized out>, r=<optimized out>, a=<optimized out>, ret=<optimized out>) at /usr/lib64/qt5/include/QtCore/qobject_impl.h:200
#10 0x0000003b7c4a532b in QMetaObject::activate(QObject*, int, int, void**) (a=0x7fffffffd4a0, r=0x662c40, this=0x65c590) at ../../src/corelib/kernel/qobject_impl.h:132
#11 0x0000003b7c4a532b in QMetaObject::activate(QObject*, int, int, void**) (sender=<optimized out>, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x0) at kernel/qobject.cpp:3666
#12 0x0000003b7c4a5c97 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=<optimized out>, m=m@entry=0x3b84459b80 <KSelectionOwner::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x0) at kernel/qobject.cpp:3546
#13 0x0000003b842497e3 in KSelectionOwner::claimedOwnership() (this=<optimized out>) at /usr/src/debug/kwindowsystem-5.0.0/build/src/moc_kselectionowner.cpp:149
Comment 1 Thomas Lübking 2014-07-24 22:14:16 UTC
Is this reproducible and do you always get the same backtrace in case?

(xcb_get_setup returning 0x0 somehow smells like the connection() is invalid at this point, but it's required before some times, eg. when querying the extension list.

Are you running this in some nested X11 server?
Comment 2 Nicolas L. 2014-07-25 10:54:02 UTC
as i can't start KF5, it kills X, i tried to start kwin_x11 under IceWM but it killed X.

So my last try ( the one that allowed me to have the trace ) was to open IceWM, go in a tty and do DISPLAY=:0 gdb --args kwin_x11  --replace


For your question, yes i can reproduce each time and the trace is always the same.
Comment 3 Thomas Lübking 2014-07-25 11:14:12 UTC
> as i can't start KF5, it kills X, i tried to start kwin_x11 under IceWM but it killed X.

-> there's hopefully a backtrace in /var/log/Xorg.0.log

This however explains the backtrace in comment #0
Since the X11 server is gone, accessing it won't work (the backtrace is therefore also irrelevant and *not* a particular bug in KWin)

The X11 server crash is (by definition, *clients* are not suppsed to crash the server ever) an Xorg bug, probably in the driver.

-> Attach mentioned log and i'll tell you more ;-)
Comment 4 Nicolas L. 2014-07-25 12:21:18 UTC
Created attachment 87945 [details]
here is the log.
Comment 5 Thomas Lübking 2014-07-25 12:26:48 UTC
The one you attached is from a running X11 server (sorry, I could have anticipated this ;-)

When you start another X11 server, the log is lost, resp. moved to "/var/log/Xorg.1.log"
Please save it right after the crash (and w/o restarting X11) or use the implicit .1. backup.
Comment 6 Nicolas L. 2014-07-25 12:44:19 UTC
Created attachment 87948 [details]
new conf file

i don't see any Xorg.1.log, but i can see a Xorg.0.log.old, but i don't see anything related to a crash inside.
Comment 7 Thomas Lübking 2014-07-25 12:50:03 UTC
That server exited cleanly.
Was this obtained right after the server crashed (on starting kwin_x11) and restarted no more than once afterwards?
Comment 8 Nicolas L. 2014-07-25 12:51:40 UTC
i used kwin_x11 --replace and as soon as X restarted i copied the file.
Comment 9 Nicolas L. 2014-07-25 12:54:40 UTC
is there a X binary i could plug gdb with to have more infos ?
Comment 10 Thomas Lübking 2014-07-25 13:37:19 UTC
Yes. The binary is (usually) "X"
ps ax | grep X

ensure to "continue" X11 before switching back to its VT
Comment 11 Nicolas L. 2014-07-25 15:18:40 UTC
btw it only crash for me in a DE "not" KF5, in KF5 all works as expected.
Comment 12 Thomas Lübking 2014-07-25 15:30:53 UTC
how do you determine that X11 crashes?
notice that for many sessions the WM could be the client that keeps the session alive, ie. if you exit (attempting to replace) it, the session exits and the DM will likely restart the server in return.
Comment 13 Thomas Lübking 2015-04-16 19:56:37 UTC

*** This bug has been marked as a duplicate of bug 343844 ***