349921 2015-07-05 09:41:27 +0000 KWin periodically hangs, mostly when opening a lots of windows at once 2016-01-19 11:12:53 +0000 1 1 4 Plasma kwin compositing git master Compiled Sources Linux RESOLVED DUPLICATE 351839 https://bugs.kde.org/show_bug.cgi?id=348834 https://bugs.kde.org/show_bug.cgi?id=351839 https://bugs.kde.org/show_bug.cgi?id=351763 NOR crash --- 0 krejzi kwin-bugs-null 0 oldest_to_newest 1530248 0 krejzi 2015-07-05 09:41:27 +0000 The hang happens periodically, as in I can't figure out what really triggers it. I have found out that at login when I start quite a number of apps at once, kwin will freeze while trying to display them. I can kill/restart kwin and everything will go back to normal. Same thing happens with Plasma 5.3.x (x = 0, 1 and 2) and Frameworks/Plasma git master from 2 days ago. Reproducible: Sometimes Steps to Reproduce: 1. Log in 2. Click Firefox, Thunderbird and Konsole from the taskbar 3. You can move the cursor, but the skeleton window of one of the apps will remain there and nothing can be done, including clicking on the taskbar and moving the cursor top-left corner doesn't bring the overview or whatever that's called. 4. Switch to tty2, log in as a normal user, killall -9 kwin_x11 5. Switch to Plasma session 6. Alt+Space -> kwin_x11 -> all normal. I am also using Qt-5.5.0 (I was using 5.4.1 and 5.4.2 too, it happened with those versions too), xorg-server git master from 2 days ago (Updated when I updated Plasma to git master, but same thing happened with 1.17.1 and 1.17.2), Mesa-10.6.1 (again, same thing happened with 10.5.x series), xf86-video-intel-2.99.917 with UXA acceleration, and Linux-4.1.0 (although it also happened with 4.0 and 3.19 series). 1530249 1 93481 krejzi 2015-07-05 09:46:18 +0000 Created attachment 93481 qdbus-qt5 org.kde.KWin /KWin supportInformation Here's also the output of qdbus-qt5 org.kde.KWin /KWin supportInformation 1530253 2 thomas.luebking 2015-07-05 09:56:47 +0000 can you suspend/resume the compositor (SHIFT+Alt+F12) and does that clear the stage as well? 1530254 3 krejzi 2015-07-05 09:57:36 +0000 I haven't tried that, but I will next time the hang occours. 1530255 4 krejzi 2015-07-05 10:05:35 +0000 Ok, logged out, logged back in, tried to start the same apps, and as expected, kwin hung, and suspending the compositor didn't work. But, I've learned something rather interesting. It doesn't hang, it crashes and it fails to properly restart itself. I have seen the following in the "ps aux" output: armin 1802 0.0 0.4 412868 27696 ? S 11:58 0:00 /usr/bin/kwin_x11 --crashes 1 armin 1803 0.0 0.6 475612 36572 ? S 11:58 0:00 /usr/lib/libexec/drkonqi -platform xcb -display :0 --appname kwin_x11 --apppath /usr/bin --signal 11 --pid 1606 --appversion 5.3.90 --programname KWin --bugaddress submit@bugs.kde.org --startupid 0 But, given that the WM is unavailable, I can't get to drkonqi at all, and restarting kwin_x11 makes drkonqi disappear. Also, while in frozen state, the qdbus-qt5 command doesn't work. Or rather, it does, but it outputs the following: Error: org.freedesktop.DBus.Error.NameHasNoOwner Name org.kde.KWin is currently not owned by anyone. 1530256 5 93483 krejzi 2015-07-05 10:16:46 +0000 Created attachment 93483 gdb backtrace of the crash Here's also the gdb backtrace when kwin crashes/hangs 1530257 6 krejzi 2015-07-05 10:25:55 +0000 Also, an interesting observation. I have found out that opening a lots of windows at once isn't the only way to reproduce the problem. When I log into Plasma and switch to tty2 to attach kwin_x11 to gdb, it instantly crashes and I can get the backtrace (I got the backtrace that way, I'm lucky drkonqi keeps it alive). But, after restarting kwin_x11 after the first crash, the problem isn't reproducible anymore, neither by opening a lots of windows at once nor switching to another VT. It's possible that kwin_x11 tries to use something that wasn't initialized at that moment, either from Qt or somewhere else. 1530275 7 thomas.luebking 2015-07-05 11:39:07 +0000 (In reply to Armin K. from comment #4) > But, given that the WM is unavailable, I can't get to drkonqi at all, and > restarting kwin_x11 makes drkonqi disappear. I'd rather say this is (if at all) a bug #348834 in drkonqi - re/starting the WM doesn't make any windows disappear. > Name org.kde.KWin is currently not owned by anyone. Since there's no running kwin process, that's not much of a surprise. > Here's also the gdb backtrace when kwin crashes/hangs The backtrace looks like the actual crash is in another thread. > It's possible that kwin_x11 tries to use something that wasn't initialized > at that moment, either from Qt or somewhere else. I'll bet your right arm on EGL (see the other bug) - please try GLX ("kcmshell5 kwincompositing") 1530278 8 krejzi 2015-07-05 12:13:38 +0000 (In reply to Thomas Lübking from comment #7) > (In reply to Armin K. from comment #4) > > But, given that the WM is unavailable, I can't get to drkonqi at all, and > > restarting kwin_x11 makes drkonqi disappear. > I'd rather say this is (if at all) a bug #348834 in drkonqi - re/starting > the WM doesn't make any windows disappear. > Well, killing the process it's trying to debug/report certainly killed drkonqi too. At least in my case. > > > Name org.kde.KWin is currently not owned by anyone. > Since there's no running kwin process, that's not much of a surprise. > There is, as shown in comment 4. But I believe that's an already crashed process trapped by drkonqi/kcrash. What made no sense to me is why it didn't restart kwin properly. Bug or feature? > > Here's also the gdb backtrace when kwin crashes/hangs > The backtrace looks like the actual crash is in another thread. > > > It's possible that kwin_x11 tries to use something that wasn't initialized > > at that moment, either from Qt or somewhere else. > I'll bet your right arm on EGL (see the other bug) - please try GLX > ("kcmshell5 kwincompositing") Okay, switched to GLX from EGL (I have no idea why I selected EGL). So far, trying the usual stuff that crashed kwin didn't trigger any crash. Still, EGL stuff ought to be fixed sometimes, even if switching to GLX fixes my problem (or note that using EGL is buggy, whatever seems easier). 1530285 9 thomas.luebking 2015-07-05 12:55:32 +0000 (In reply to Armin K. from comment #8) > There is, as shown in comment 4. *running* - as opposed to "stopped" ;-) > restart kwin properly. Bug or feature? From the dupe, the crashed kwin process (at least in this zombie mode) fails to release the WM selection; therefore the new kwin process cannot take it and immediately stops (that's a requirement for WMs since it needs to be a singleton process) => the bug is that for whatever reason the kwin process held by drkonqi doesn't get rid of the WM selection. Usually this should happen automagically, because the selection is claimed via a helper window and when kwin crashes, the connection to the X11 server gets cut and the X11 server would remove that window - and the selection with it... > Still, EGL stuff ought to be fixed sometimes We'd need a backtrace for that (the thread you presented just informs us that something could not connect the X11 server, and that's simply because kwin just crashed) - at least to see whether that's something in kwin or in the driver. 1530287 10 krejzi 2015-07-05 13:07:48 +0000 (In reply to Thomas Lübking from comment #9) > (In reply to Armin K. from comment #8) > > There is, as shown in comment 4. > *running* - as opposed to "stopped" ;-) > > > restart kwin properly. Bug or feature? > From the dupe, the crashed kwin process (at least in this zombie mode) fails > to release the WM selection; therefore the new kwin process cannot take it > and immediately stops (that's a requirement for WMs since it needs to be a > singleton process) => the bug is that for whatever reason the kwin process > held by drkonqi doesn't get rid of the WM selection. > > Usually this should happen automagically, because the selection is claimed > via a helper window and when kwin crashes, the connection to the X11 server > gets cut and the X11 server would remove that window - and the selection > with it... > I have "disabled" drkonqi by exporting KDE_DEBUG=1 as advised on irc. Now, kwin crashed again, and no drkonqi instance was started. I saw kwin restarted itself (ps shows kwin_x11 started with --crashes 1), but it wasn't working properly, ie no borders, decorations, etc. I had to kill it myself and start it again from krunner. Is this related to what you said here, or is it something else entirely? > > Still, EGL stuff ought to be fixed sometimes > We'd need a backtrace for that (the thread you presented just informs us > that something could not connect the X11 server, and that's simply because > kwin just crashed) - at least to see whether that's something in kwin or in > the driver. Ok, I'll try utilizing systemd coredumps for this. 1532232 11 thomas.luebking 2015-07-18 14:39:23 +0000 (In reply to Armin K. from comment #10) > it wasn't working properly, ie no borders, decorations, etc. Sounds (if you could still Alt+left mouse button move windows) like no proper decoration plugin lib was found - what's rather weird if it works when restarting it by hand... I don't think this has direct relation, but could indicate a broken installation where different plugin libs are resolved depending on the startup environment. > Ok, I'll try utilizing systemd coredumps for this. Any success on this? 1532666 12 krejzi 2015-07-21 12:27:16 +0000 (In reply to Thomas Lübking from comment #11) > (In reply to Armin K. from comment #10) > > > it wasn't working properly, ie no borders, decorations, etc. > Sounds (if you could still Alt+left mouse button move windows) like no > proper decoration plugin lib was found - what's rather weird if it works > when restarting it by hand... > > I don't think this has direct relation, but could indicate a broken > installation where different plugin libs are resolved depending on the > startup environment. > I've seen kwin crashing but properly restarting itself with drkonqi disabled. It seems the issue went away. > > Ok, I'll try utilizing systemd coredumps for this. > Any success on this? I was away for some time and didn't use my linux install. I've built all plasma packages from git on Sunday and have now switched KWin to use EGL instead of GLX. But, I did notice one thing: KWin crash doesn't produce something like Jul 19 18:19:02 krejzi kernel: kactivitymanage[11604]: segfault at 7f25b19e2770 ip 00007f25b1c28711 sp 00007ffeec54c3d8 error 4 in libQt5Sql.so.5.5.0[7f25b1c14000+3f000] In the system log, and systemd-coredump only catches these afaik. Still, I'll try and see what can be done (unless the issue went away with latest snapshot that is). 1532959 13 krejzi 2015-07-23 08:55:48 +0000 (In reply to Armin K. from comment #12) > (In reply to Thomas Lübking from comment #11) > > (In reply to Armin K. from comment #10) > > > > > it wasn't working properly, ie no borders, decorations, etc. > > Sounds (if you could still Alt+left mouse button move windows) like no > > proper decoration plugin lib was found - what's rather weird if it works > > when restarting it by hand... > > > > I don't think this has direct relation, but could indicate a broken > > installation where different plugin libs are resolved depending on the > > startup environment. > > > > I've seen kwin crashing but properly restarting itself with drkonqi > disabled. It seems the issue went away. > > > > Ok, I'll try utilizing systemd coredumps for this. > > Any success on this? > > I was away for some time and didn't use my linux install. I've built all > plasma packages from git on Sunday and have now switched KWin to use EGL > instead of GLX. > > But, I did notice one thing: KWin crash doesn't produce something like > > Jul 19 18:19:02 krejzi kernel: kactivitymanage[11604]: segfault at > 7f25b19e2770 ip 00007f25b1c28711 sp 00007ffeec54c3d8 error 4 in > libQt5Sql.so.5.5.0[7f25b1c14000+3f000] > > In the system log, and systemd-coredump only catches these afaik. Still, > I'll try and see what can be done (unless the issue went away with latest > snapshot that is). Ok, ignore this comment. I was able to get kwin_x11 to crash and generate a backtrace using the core obtained from coredumpctl. I did rebuild Qt5 (most of it, anyways) with debug symbols (although in release mode as debug mode would make other KDE components crash, so it was built with -O2 -g and not stripped). Same goes for kwin, except it was built in true debug mode, no optimization. Still, I'm missing some symbols and have no idea where they come from. If anyone has any pointers about them, please let me know what I need to rebuild/install. Core was generated by `kwin_x11'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fe1bdd1d469 in raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/pt-raise.c:36 36 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory. (gdb) bt #0 0x00007fe1bdd1d469 in raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/pt-raise.c:36 #1 0x00007fe1c39d8986 in KCrash::defaultCrashHandler (sig=11) at /home/armin/src/frameworks/kcrash-5.12.0/src/kcrash.cpp:409 #2 <signal handler called> #3 ref (this=0x0) at /usr/include/qt5/QtCore/qrefcount.h:54 #4 toQString (this=<optimized out>) at jsruntime/qv4string_p.h:81 #5 toQString (this=<optimized out>) at jsruntime/qv4string_p.h:141 #6 QV4::Heap::StringObject::StringObject (this=<optimized out>, engine=0x28ccc40, val=...) at jsruntime/qv4stringobject.cpp:91 #7 0x00007fe1c28566e3 in alloc<QV4::StringObject, QV4::ExecutionEngine*, QV4::Value> (arg2=..., arg1=0x28ccc40, this=<optimized out>) at jsruntime/qv4mm_p.h:117 #8 QV4::ExecutionEngine::newStringObject (this=0x28ccc40, value=...) at jsruntime/qv4engine.cpp:552 #9 0x00007fe1c28edc7f in QV4::Runtime::getProperty (engine=0x28ccc40, object=..., nameIndex=<optimized out>) at jsruntime/qv4runtime.cpp:679 #10 0x00007fe10e762089 in ?? () #11 0x00007fe1c34ba6a2 in QQuickItem::staticMetaObject () from /usr/lib/libQt5Quick.so.5 #12 0x00007fe1071b5238 in ?? () #13 0x0000000002e66e10 in ?? () #14 0x00007fe1071b5230 in ?? () #15 0x00000000028ccc40 in ?? () #16 0x00007fe1bbe8b199 in CallConstructor (this=<synthetic pointer>, tc=<synthetic pointer>) at ../../include/QtCore/5.5.0/QtCore/private/../../../../../src/corelib/kernel/qvariant_p.h:339 #17 FilteredConstructor (this=<optimized out>, tc=<synthetic pointer>) at ../../include/QtCore/5.5.0/QtCore/private/../../../../../src/corelib/kernel/qvariant_p.h:362 #18 delegate<QIcon> (this=<synthetic pointer>) at ../../include/QtCore/5.5.0/QtCore/private/../../../../../src/corelib/kernel/qvariant_p.h:383 #19 switcher<void, QVariantConstructor<(anonymous namespace)::GuiTypesFilter> > (data=0x0, type=<optimized out>, logic=<synthetic pointer>) at ../../include/QtCore/5.5.0/QtCore/private/../../../../../src/corelib/kernel/qmetatypeswitcher_p.h:68 #20 (anonymous namespace)::construct (x=0x2ba9620, copy=0x7ffc9df477a0) at kernel/qguivariant.cpp:101 #21 0x00000000028ccc40 in ?? () #22 0x00000000028ccc40 in ?? () #23 0x0000000002e9dc78 in ?? () #24 0x0000000000000003 in ?? () #25 0x00000000028a8a10 in ?? () #26 0x00007fe1c2cdb520 in ?? () from /usr/lib/libQt5Qml.so.5 #27 0x00007fe1071b51d0 in ?? () #28 0x00000000028ccc40 in ?? () #29 0x00007ffc9df48220 in ?? () #30 0x00007fe10e2c40f0 in ?? () #31 0x0000000000000000 in ?? () Coredumpctl output reports something less longer: Stack trace of thread 618: #0 0x00007fe1bdd1d469 raise (libpthread.so.0) #1 0x00007fe1c39d8986 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5) #2 0x00007fe1ba3874a0 __restore_rt (libc.so.6) #3 0x00007fe1c28ae192 _ZN9QtPrivate8RefCount3refEv (libQt5Qml.so.5) #4 0x00007fe1c28566e3 _ZN3QV413MemoryManager5allocINS_12StringObjectEPNS_15ExecutionEngineENS_5ValueEEEPNT_4DataET0_T1_ (libQt5Qml.so.5) #5 0x00007fe1c28edc7f _ZN3QV47Runtime11getPropertyEPNS_15ExecutionEngineERKNS_5ValueEi (libQt5Qml.so.5) #6 0x00007fe10e762089 n/a (n/a) 1532990 14 thomas.luebking 2015-07-23 13:07:10 +0000 The problem is (likely) > Plugin: org.kde.kwin.aurorae > Theme: kwin4_decoration_qml_plastik but the particular crash could be introduced with Qt5.5 (at least there *was* a regression in alpha versions: https://bugreports.qt.io/browse/QTCREATORBUG-14595 it's supposed to be fixed in the release, but that doesn't mean there's no other bug introduced in that context. => switch to the breeze decoration (the supportInformation say that you're using the breeze plugin, NOT the aurorae plugin with some breeze theme) and see whether you can re-cause a) the crash (unlikely) b) the stall (most interesting question) 1532992 15 krejzi 2015-07-23 13:18:06 +0000 (In reply to Thomas Lübking from comment #14) > The problem is (likely) > > Plugin: org.kde.kwin.aurorae > > Theme: kwin4_decoration_qml_plastik > > but the particular crash could be introduced with Qt5.5 (at least there > *was* a regression in alpha versions: > https://bugreports.qt.io/browse/QTCREATORBUG-14595 > > it's supposed to be fixed in the release, but that doesn't mean there's no > other bug introduced in that context. > I was bitten by that bug in a way that plasma wouldn't start. I can confirm the issue was fixed in Qt-5.5-rc. However, my original issue happened with Qt-5.4.1 and Qt-5.4.2 too, although I'm not sure if the backtrace is similar. > => switch to the breeze decoration (the supportInformation say that you're > using the breeze plugin, NOT the aurorae plugin with some breeze theme) and > see whether you can re-cause > a) the crash (unlikely) > b) the stall (most interesting question) How do I switch to breeze decoration? I have selected breeze in systemsettings wherever it was possible. I do remember a similar bug due to using aurorae engine which was around before kdecoration2 port https://bugs.kde.org/show_bug.cgi?id=341110 But doesn't seem the same issue. 1532993 16 krejzi 2015-07-23 13:22:57 +0000 (In reply to Armin K. from comment #15) > (In reply to Thomas Lübking from comment #14) > > => switch to the breeze decoration (the supportInformation say that you're > > using the breeze plugin, NOT the aurorae plugin with some breeze theme) and > > see whether you can re-cause > > a) the crash (unlikely) > > b) the stall (most interesting question) > > How do I switch to breeze decoration? Ok, nevermind. I found it. It's really ugly and unusable for me, but it does say org.kde.breeze now instead of aurorae. I can handle it long enough to try and reproduce the crash. 1532994 17 thomas.luebking 2015-07-23 13:24:41 +0000 you can configure it to a certain degree - notably turn the buttons smaller ;-) 1534273 18 krejzi 2015-07-31 10:10:54 +0000 After some time of using the breeze instead of aurorae engine or whatever it's called, there wasn't a single crash. 1534318 19 thomas.luebking 2015-07-31 14:37:34 +0000 and about hangs (ie. the original report)? 1535097 20 krejzi 2015-08-04 21:05:01 +0000 (In reply to Thomas Lübking from comment #19) > and about hangs (ie. the original report)? No. The hangs stopped as soon as I disabled drkonqi. 1570574 21 thomas.luebking 2016-01-19 11:12:53 +0000 Marking as dupe for the core segfault, drkonqi issue is hopefully resolved in 5.6 *** This bug has been marked as a duplicate of bug 351839 *** 93481 2015-07-05 09:46:18 +0000 2015-07-05 09:46:18 +0000 qdbus-qt5 org.kde.KWin /KWin supportInformation kwin-supportinfo.txt text/plain 5598 krejzi S1dpbiBTdXBwb3J0IEluZm9ybWF0aW9uOgpUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSB1c2VkIHdoZW4gcmVxdWVzdGluZyBzdXBwb3J0IG9uIGUuZy4gaHR0cDovL2ZvcnVtLmtk ZS5vcmcuCkl0IHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50bHkgcnVubmlu ZyBpbnN0YW5jZSwgd2hpY2ggb3B0aW9ucyBhcmUgdXNlZCwKd2hhdCBPcGVuR0wgZHJpdmVyIGFu ZCB3aGljaCBlZmZlY3RzIGFyZSBydW5uaW5nLgpQbGVhc2UgcG9zdCB0aGUgaW5mb3JtYXRpb24g cHJvdmlkZWQgdW5kZXJuZWF0aCB0aGlzIGludHJvZHVjdG9yeSB0ZXh0IHRvIGEgcGFzdGUgYmlu IHNlcnZpY2UKbGlrZSBodHRwOi8vcGFzdGUua2RlLm9yZyBpbnN0ZWFkIG9mIHBhc3RpbmcgaW50 byBzdXBwb3J0IHRocmVhZHMuCgo9PT09PT09PT09PT09PT09PT09PT09PT09PQoKVmVyc2lvbgo9 PT09PT09CktXaW4gdmVyc2lvbjogNS4zLjkwClF0IFZlcnNpb246IDUuNS4wClF0IGNvbXBpbGUg dmVyc2lvbjogNS41LjAKWENCIGNvbXBpbGUgdmVyc2lvbjogMS4xMQoKT3BlcmF0aW9uIE1vZGU6 IFgxMSBvbmx5CgpCdWlsZCBPcHRpb25zCj09PT09PT09PT09PT0KS1dJTl9CVUlMRF9ERUNPUkFU SU9OUzogeWVzCktXSU5fQlVJTERfVEFCQk9YOiB5ZXMKS1dJTl9CVUlMRF9BQ1RJVklUSUVTOiB5 ZXMKSEFWRV9XQVlMQU5EOiB5ZXMKSEFWRV9XQVlMQU5EX0VHTDogeWVzCkhBVkVfV0FZTEFORF9D VVJTT1I6IHllcwpIQVZFX1hLQjogeWVzCkhBVkVfSU5QVVQ6IHllcwpIQVZFX0RSTTogeWVzCkhB VkVfR0JNOiB5ZXMKSEFWRV9YMTFfWENCOiB5ZXMKClgxMQo9PT0KVmVuZG9yOiBUaGUgWC5Pcmcg Rm91bmRhdGlvbgpWZW5kb3IgUmVsZWFzZTogMTE3OTkwMDAKUHJvdG9jb2wgVmVyc2lvbi9SZXZp c2lvbjogMTEvMApTSEFQRTogeWVzOyBWZXJzaW9uOiAweDExClJBTkRSOiB5ZXM7IFZlcnNpb246 IDB4MTQKREFNQUdFOiB5ZXM7IFZlcnNpb246IDB4MTEKQ29tcG9zaXRlOiB5ZXM7IFZlcnNpb246 IDB4NApSRU5ERVI6IHllczsgVmVyc2lvbjogMHhiClhGSVhFUzogeWVzOyBWZXJzaW9uOiAweDUw ClNZTkM6IHllczsgVmVyc2lvbjogMHgzMQpHTFg6IHllczsgVmVyc2lvbjogMHgwCgpEZWNvcmF0 aW9uCj09PT09PT09PT0KUGx1Z2luOiBvcmcua2RlLmt3aW4uYXVyb3JhZQpUaGVtZToga3dpbjRf ZGVjb3JhdGlvbl9xbWxfcGxhc3RpawpCbHVyOiAxCm9uQWxsRGVza3RvcHNBdmFpbGFibGU6IHRy dWUKYWxwaGFDaGFubmVsU3VwcG9ydGVkOiB0cnVlCmNsb3NlT25Eb3VibGVDbGlja09uTWVudTog ZmFsc2UKZGVjb3JhdGlvbkJ1dHRvbnNMZWZ0OiAwLCAyCmRlY29yYXRpb25CdXR0b25zUmlnaHQ6 IDYsIDMsIDQsIDUKYm9yZGVyU2l6ZTogMwpncmlkVW5pdDogMTAKZm9udDogT3h5Z2VuLVNhbnMs MTAsLTEsMCw1MCwwLDAsMCwwLDAKc21hbGxTcGFjaW5nOiAyCmxhcmdlU3BhY2luZzogMTAKCk9w dGlvbnMKPT09PT09PQpmb2N1c1BvbGljeTogMApuZXh0Rm9jdXNQcmVmZXJzTW91c2U6IGZhbHNl CmNsaWNrUmFpc2U6IHRydWUKYXV0b1JhaXNlOiBmYWxzZQphdXRvUmFpc2VJbnRlcnZhbDogMApk ZWxheUZvY3VzSW50ZXJ2YWw6IDAKc2hhZGVIb3ZlcjogZmFsc2UKc2hhZGVIb3ZlckludGVydmFs OiAyNTAKc2VwYXJhdGVTY3JlZW5Gb2N1czogZmFsc2UKcGxhY2VtZW50OiA0CmZvY3VzUG9saWN5 SXNSZWFzb25hYmxlOiB0cnVlCmJvcmRlclNuYXBab25lOiAxMAp3aW5kb3dTbmFwWm9uZTogMTAK Y2VudGVyU25hcFpvbmU6IDAKc25hcE9ubHlXaGVuT3ZlcmxhcHBpbmc6IGZhbHNlCnJvbGxPdmVy RGVza3RvcHM6IHRydWUKZm9jdXNTdGVhbGluZ1ByZXZlbnRpb25MZXZlbDogMQpsZWdhY3lGdWxs c2NyZWVuU3VwcG9ydDogZmFsc2UKb3BlcmF0aW9uVGl0bGViYXJEYmxDbGljazogNTAwMApvcGVy YXRpb25NYXhCdXR0b25MZWZ0Q2xpY2s6IDUwMDAKb3BlcmF0aW9uTWF4QnV0dG9uTWlkZGxlQ2xp Y2s6IDUwMTUKb3BlcmF0aW9uTWF4QnV0dG9uUmlnaHRDbGljazogNTAxNApjb21tYW5kQWN0aXZl VGl0bGViYXIxOiAwCmNvbW1hbmRBY3RpdmVUaXRsZWJhcjI6IDMwCmNvbW1hbmRBY3RpdmVUaXRs ZWJhcjM6IDIKY29tbWFuZEluYWN0aXZlVGl0bGViYXIxOiA0CmNvbW1hbmRJbmFjdGl2ZVRpdGxl YmFyMjogMzAKY29tbWFuZEluYWN0aXZlVGl0bGViYXIzOiAyCmNvbW1hbmRXaW5kb3cxOiA3CmNv bW1hbmRXaW5kb3cyOiA4CmNvbW1hbmRXaW5kb3czOiA4CmNvbW1hbmRXaW5kb3dXaGVlbDogMzEK Y29tbWFuZEFsbDE6IDEwCmNvbW1hbmRBbGwyOiAzCmNvbW1hbmRBbGwzOiAxNAprZXlDbWRBbGxN b2RLZXk6IDE2Nzc3MjUxCnNob3dHZW9tZXRyeVRpcDogZmFsc2UKY29uZGVuc2VkVGl0bGU6IGZh bHNlCmVsZWN0cmljQm9yZGVyTWF4aW1pemU6IHRydWUKZWxlY3RyaWNCb3JkZXJUaWxpbmc6IHRy dWUKZWxlY3RyaWNCb3JkZXJDb3JuZXJSYXRpbzogMC4yNQpib3JkZXJsZXNzTWF4aW1pemVkV2lu ZG93czogZmFsc2UKa2lsbFBpbmdUaW1lb3V0OiA1MDAwCmhpZGVVdGlsaXR5V2luZG93c0Zvcklu YWN0aXZlOiB0cnVlCmluYWN0aXZlVGFic1NraXBUYXNrYmFyOiBmYWxzZQphdXRvZ3JvdXBTaW1p bGFyV2luZG93czogZmFsc2UKYXV0b2dyb3VwSW5Gb3JlZ3JvdW5kOiB0cnVlCmNvbXBvc2l0aW5n TW9kZTogMQp1c2VDb21wb3NpdGluZzogdHJ1ZQpjb21wb3NpdGluZ0luaXRpYWxpemVkOiB0cnVl CmhpZGRlblByZXZpZXdzOiAxCnVucmVkaXJlY3RGdWxsc2NyZWVuOiBmYWxzZQpnbFNtb290aFNj YWxlOiAyCmNvbG9yQ29ycmVjdGVkOiBmYWxzZQp4cmVuZGVyU21vb3RoU2NhbGU6IGZhbHNlCm1h eEZwc0ludGVydmFsOiAxNjY2NjY2NgpyZWZyZXNoUmF0ZTogMAp2QmxhbmtUaW1lOiA2MDAwMDAw CmdsU3RyaWN0QmluZGluZzogZmFsc2UKZ2xTdHJpY3RCaW5kaW5nRm9sbG93c0RyaXZlcjogdHJ1 ZQpnbENvcmVQcm9maWxlOiB0cnVlCmdsUHJlZmVyQnVmZmVyU3dhcDogMTAxCmdsUGxhdGZvcm1J bnRlcmZhY2U6IDIKClNjcmVlbiBFZGdlcwo9PT09PT09PT09PT0KZGVza3RvcFN3aXRjaGluZzog ZmFsc2UKZGVza3RvcFN3aXRjaGluZ01vdmluZ0NsaWVudHM6IGZhbHNlCmN1cnNvclB1c2hCYWNr RGlzdGFuY2U6IDF4MQp0aW1lVGhyZXNob2xkOiAxNTAKcmVBY3RpdmF0ZVRocmVzaG9sZDogMzUw CmFjdGlvblRvcExlZnQ6IDAKYWN0aW9uVG9wOiAwCmFjdGlvblRvcFJpZ2h0OiAwCmFjdGlvblJp Z2h0OiAwCmFjdGlvbkJvdHRvbVJpZ2h0OiAwCmFjdGlvbkJvdHRvbTogMAphY3Rpb25Cb3R0b21M ZWZ0OiAwCmFjdGlvbkxlZnQ6IDAKClNjcmVlbnMKPT09PT09PQpNdWx0aS1IZWFkOiBubwpBY3Rp dmUgc2NyZWVuIGZvbGxvd3MgbW91c2U6ICBubwpOdW1iZXIgb2YgU2NyZWVuczogMQoKU2NyZWVu IDA6Ci0tLS0tLS0tLQpOYW1lOiBMVkRTMQpHZW9tZXRyeTogMCwwLDEzNjZ4NzY4ClJlZnJlc2gg UmF0ZTogNjAuMDMxMgoKCkNvbXBvc2l0aW5nCj09PT09PT09PT09CkNvbXBvc2l0aW5nIGlzIGFj dGl2ZQpDb21wb3NpdGluZyBUeXBlOiBPcGVuR0wKT3BlbkdMIHZlbmRvciBzdHJpbmc6IEludGVs IE9wZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyCk9wZW5HTCByZW5kZXJlciBzdHJpbmc6IE1l c2EgRFJJIEludGVsKFIpIFNhbmR5YnJpZGdlIE1vYmlsZSAKT3BlbkdMIHZlcnNpb24gc3RyaW5n OiAzLjMgKENvcmUgUHJvZmlsZSkgTWVzYSAxMC42LjEKT3BlbkdMIHBsYXRmb3JtIGludGVyZmFj ZTogRUdMCk9wZW5HTCBzaGFkaW5nIGxhbmd1YWdlIHZlcnNpb24gc3RyaW5nOiAzLjMwCkRyaXZl cjogSW50ZWwKR1BVIGNsYXNzOiBTYW5keUJyaWRnZQpPcGVuR0wgdmVyc2lvbjogMy4zCkdMU0wg dmVyc2lvbjogMy4zMApNZXNhIHZlcnNpb246IDEwLjYuMQpYIHNlcnZlciB2ZXJzaW9uOiAxLjE3 Ljk5CkxpbnV4IGtlcm5lbCB2ZXJzaW9uOiA0LjEKRGlyZWN0IHJlbmRlcmluZzogUmVxdWlyZXMg c3RyaWN0IGJpbmRpbmc6IG5vCkdMU0wgc2hhZGVyczogIHllcwpUZXh0dXJlIE5QT1Qgc3VwcG9y dDogIHllcwpWaXJ0dWFsIE1hY2hpbmU6ICBubwpPcGVuR0wgMiBTaGFkZXJzIGFyZSB1c2VkClBh aW50aW5nIGJsb2NrcyBmb3IgdmVydGljYWwgcmV0cmFjZTogIG5vCgpMb2FkZWQgRWZmZWN0czoK LS0tLS0tLS0tLS0tLS0tCnpvb20Kc2xpZGluZ3BvcHVwcwprd2luNF9lZmZlY3RfbG9naW4Kc2xp ZGUKc2NyZWVuc2hvdAptaW5pbWl6ZWFuaW1hdGlvbgprd2luNF9lZmZlY3RfdHJhbnNsdWNlbmN5 CmRlc2t0b3BncmlkCmt3aW40X2VmZmVjdF93aW5kb3dhcGVydHVyZQprd2luNF9lZmZlY3RfZmFk ZQprd2luNF9lZmZlY3RfbWF4aW1pemUKcHJlc2VudHdpbmRvd3MKa3dpbjRfZWZmZWN0X2RpYWxv Z3BhcmVudApoaWdobGlnaHR3aW5kb3cKYmx1cgpjb250cmFzdApsb2dvdXQKZGFzaGJvYXJkCnN0 YXJ0dXBmZWVkYmFjawpzY3JlZW5lZGdlCmtzY3JlZW4KCkN1cnJlbnRseSBBY3RpdmUgRWZmZWN0 czoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpibHVyCmNvbnRyYXN0CgpFZmZlY3QgU2V0dGlu Z3M6Ci0tLS0tLS0tLS0tLS0tLS0Kem9vbToKem9vbUZhY3RvcjogMS4yCm1vdXNlUG9pbnRlcjog MAptb3VzZVRyYWNraW5nOiAwCmVuYWJsZUZvY3VzVHJhY2tpbmc6IGZhbHNlCmZvbGxvd0ZvY3Vz OiB0cnVlCmZvY3VzRGVsYXk6IDM1MAptb3ZlRmFjdG9yOiAyMAp0YXJnZXRab29tOiAxCgpzbGlk aW5ncG9wdXBzOgpmYWRlSW5UaW1lOiAxNTAKZmFkZU91dFRpbWU6IDI1MAoKa3dpbjRfZWZmZWN0 X2xvZ2luOgoKc2xpZGU6CgpzY3JlZW5zaG90OgoKbWluaW1pemVhbmltYXRpb246Cgprd2luNF9l ZmZlY3RfdHJhbnNsdWNlbmN5OgoKZGVza3RvcGdyaWQ6Cnpvb21EdXJhdGlvbjogMzAwCmJvcmRl cjogMTAKZGVza3RvcE5hbWVBbGlnbm1lbnQ6IDAKbGF5b3V0TW9kZTogMApjdXN0b21MYXlvdXRS b3dzOiAyCnVzZVByZXNlbnRXaW5kb3dzOiB0cnVlCgprd2luNF9lZmZlY3Rfd2luZG93YXBlcnR1 cmU6Cgprd2luNF9lZmZlY3RfZmFkZToKCmt3aW40X2VmZmVjdF9tYXhpbWl6ZToKCnByZXNlbnR3 aW5kb3dzOgpsYXlvdXRNb2RlOiAwCnNob3dDYXB0aW9uczogdHJ1ZQpzaG93SWNvbnM6IHRydWUK ZG9Ob3RDbG9zZVdpbmRvd3M6IGZhbHNlCmlnbm9yZU1pbmltaXplZDogZmFsc2UKYWNjdXJhY3k6 IDIwCmZpbGxHYXBzOiB0cnVlCmZhZGVEdXJhdGlvbjogMTUwCnNob3dQYW5lbDogZmFsc2UKbGVm dEJ1dHRvbldpbmRvdzogMQpyaWdodEJ1dHRvbldpbmRvdzogMgptaWRkbGVCdXR0b25XaW5kb3c6 IDAKbGVmdEJ1dHRvbkRlc2t0b3A6IDIKbWlkZGxlQnV0dG9uRGVza3RvcDogMApyaWdodEJ1dHRv bkRlc2t0b3A6IDAKCmt3aW40X2VmZmVjdF9kaWFsb2dwYXJlbnQ6CgpoaWdobGlnaHR3aW5kb3c6 CgpibHVyOgpibHVyUmFkaXVzOiAxMgpjYWNoZVRleHR1cmU6IHRydWUKCmNvbnRyYXN0OgoKbG9n b3V0Ogp1c2VCbHVyOiB0cnVlCgpkYXNoYm9hcmQ6CmJyaWdodG5lc3M6IDAuNQpzYXR1cmF0aW9u OiAwLjUKYmx1cjogZmFsc2UKCnN0YXJ0dXBmZWVkYmFjazoKdHlwZTogMQoKc2NyZWVuZWRnZToK CmtzY3JlZW46CgoK 93483 2015-07-05 10:16:46 +0000 2015-07-05 10:16:46 +0000 gdb backtrace of the crash gdb.txt text/plain 2750 krejzi IzAgIDB4MDAwMDdmYThmNWQwN2QxZCBpbiBwb2xsICgpIGF0IC4uL3N5c2RlcHMvdW5peC9zeXNj YWxsLXRlbXBsYXRlLlM6ODEKIzEgIDB4MDAwMDdmYThmNmQ1MjIzMiBpbiBfeGNiX2Nvbm5fd2Fp dCAoYz0weDI1YzliMTAsIGNvbmQ9PG9wdGltaXplZCBvdXQ+LCB2ZWN0b3I9MHgwLCBjb3VudD0w eDApIGF0IHhjYl9jb25uLmM6NDU5CiMyICAweDAwMDA3ZmE4ZjZkNTNiNTcgaW4gd2FpdF9mb3Jf cmVwbHkgKGM9Y0BlbnRyeT0weDI1YzliMTAsIHJlcXVlc3Q9MjY5OCwgZT1lQGVudHJ5PTB4MCkg YXQgeGNiX2luLmM6NDkxCiMzICAweDAwMDA3ZmE4ZjZkNTNjNjEgaW4geGNiX3dhaXRfZm9yX3Jl cGx5IChjPTB4MjVjOWIxMCwgcmVxdWVzdD0yNjk4LCBlPTB4MCkgYXQgeGNiX2luLmM6NTIxCiM0 ICAweDAwMDA3ZmE4ZTZmZGMxYWEgaW4gUVhjYkNvbm5lY3Rpb246OnN5bmMoKSAoKSBmcm9tIC91 c3IvbGliL2xpYlF0NVhjYlFwYS5zby41CiM1ICAweDAwMDA3ZmE4ZTZmZGQ2ZTggaW4gUVhjYkNv bm5lY3Rpb246OmdldFRpbWVzdGFtcCgpICgpIGZyb20gL3Vzci9saWIvbGliUXQ1WGNiUXBhLnNv LjUKIzYgIDB4MDAwMDdmYThlNmZmY2Y1MiBpbiBRWGNiTmF0aXZlSW50ZXJmYWNlOjpnZXRUaW1l c3RhbXAoUVhjYlNjcmVlbiBjb25zdCopICgpIGZyb20gL3Vzci9saWIvbGliUXQ1WGNiUXBhLnNv LjUKIzcgIDB4MDAwMDdmYThlNmZmZGJkYSBpbiBRWGNiTmF0aXZlSW50ZXJmYWNlOjpuYXRpdmVS ZXNvdXJjZUZvclNjcmVlbihRQnl0ZUFycmF5IGNvbnN0JiwgUVNjcmVlbiopICgpIGZyb20gL3Vz ci9saWIvbGliUXQ1WGNiUXBhLnNvLjUKIzggIDB4MDAwMDdmYThmODYwNTcxMCBpbiBRWDExSW5m bzo6Z2V0VGltZXN0YW1wKCkgKCkgZnJvbSAvdXNyL2xpYi9saWJRdDVYMTFFeHRyYXMuc28uNQoj OSAgMHgwMDAwN2ZhOTAwMzgxMzE5IGluID8/ICgpIGZyb20gL3Vzci9saWIvbGlia3dpbi5zby41 CiMxMCAweDAwMDA3ZmE5MDAzOWIxMGYgaW4gS1dpbjo6V29ya3NwYWNlOjp3b3Jrc3BhY2VFdmVu dCh4Y2JfZ2VuZXJpY19ldmVudF90KikgKCkgZnJvbSAvdXNyL2xpYi9saWJrd2luLnNvLjUKIzEx IDB4MDAwMDdmYThmNzFlZDFiZiBpbiBRQWJzdHJhY3RFdmVudERpc3BhdGNoZXI6OmZpbHRlck5h dGl2ZUV2ZW50KFFCeXRlQXJyYXkgY29uc3QmLCB2b2lkKiwgbG9uZyopICgpIGZyb20gL3Vzci9s aWIvbGliUXQ1Q29yZS5zby41CiMxMiAweDAwMDA3ZmE4ZTZmZTBiMDQgaW4gUVhjYkNvbm5lY3Rp b246OmhhbmRsZVhjYkV2ZW50KHhjYl9nZW5lcmljX2V2ZW50X3QqKSAoKSBmcm9tIC91c3IvbGli L2xpYlF0NVhjYlFwYS5zby41CiMxMyAweDAwMDA3ZmE4ZTZmZTE4YjMgaW4gUVhjYkNvbm5lY3Rp b246OnByb2Nlc3NYY2JFdmVudHMoKSAoKSBmcm9tIC91c3IvbGliL2xpYlF0NVhjYlFwYS5zby41 CiMxNCAweDAwMDA3ZmE4ZjcyMWZlNzEgaW4gUU9iamVjdDo6ZXZlbnQoUUV2ZW50KikgKCkgZnJv bSAvdXNyL2xpYi9saWJRdDVDb3JlLnNvLjUKIzE1IDB4MDAwMDdmYThmN2VkNDNjYyBpbiBRQXBw bGljYXRpb25Qcml2YXRlOjpub3RpZnlfaGVscGVyKFFPYmplY3QqLCBRRXZlbnQqKSAoKSBmcm9t IC91c3IvbGliL2xpYlF0NVdpZGdldHMuc28uNQojMTYgMHgwMDAwN2ZhOGY3ZWQ5ODU2IGluIFFB cHBsaWNhdGlvbjo6bm90aWZ5KFFPYmplY3QqLCBRRXZlbnQqKSAoKSBmcm9tIC91c3IvbGliL2xp YlF0NVdpZGdldHMuc28uNQojMTcgMHgwMDAwN2ZhOGY3MWYwNmFiIGluIFFDb3JlQXBwbGljYXRp b246Om5vdGlmeUludGVybmFsKFFPYmplY3QqLCBRRXZlbnQqKSAoKSBmcm9tIC91c3IvbGliL2xp YlF0NUNvcmUuc28uNQojMTggMHgwMDAwN2ZhOGY3MWYyYWY2IGluIFFDb3JlQXBwbGljYXRpb25Q cml2YXRlOjpzZW5kUG9zdGVkRXZlbnRzKFFPYmplY3QqLCBpbnQsIFFUaHJlYWREYXRhKikgKCkg ZnJvbSAvdXNyL2xpYi9saWJRdDVDb3JlLnNvLjUKIzE5IDB4MDAwMDdmYThmNzI0NGMyMiBpbiBR RXZlbnREaXNwYXRjaGVyVU5JWDo6cHJvY2Vzc0V2ZW50cyhRRmxhZ3M8UUV2ZW50TG9vcDo6UHJv Y2Vzc0V2ZW50c0ZsYWc+KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0NUNvcmUuc28uNQojMjAgMHgw MDAwN2ZhOGU3MDQzYTZkIGluID8/ICgpIGZyb20gL3Vzci9saWIvbGliUXQ1WGNiUXBhLnNvLjUK IzIxIDB4MDAwMDdmYThmNzFlZTA1YSBpbiBRRXZlbnRMb29wOjpleGVjKFFGbGFnczxRRXZlbnRM b29wOjpQcm9jZXNzRXZlbnRzRmxhZz4pICgpIGZyb20gL3Vzci9saWIvbGliUXQ1Q29yZS5zby41 CiMyMiAweDAwMDA3ZmE4ZjcxZjYwZWMgaW4gUUNvcmVBcHBsaWNhdGlvbjo6ZXhlYygpICgpIGZy b20gL3Vzci9saWIvbGliUXQ1Q29yZS5zby41CiMyMyAweDAwMDA3ZmE5MDA3N2RiMWIgaW4ga2Rl bWFpbiAoKSBmcm9tIC91c3IvbGliL2xpYmtkZWluaXQ1X2t3aW5feDExLnNvCiMyNCAweDAwMDA3 ZmE4ZjVjNDk3NzAgaW4gX19saWJjX3N0YXJ0X21haW4gKG1haW49MHg0MDBiYzAgPG1haW4+LCBh cmdjPTEsIGFyZ3Y9MHg3ZmZmNWIzYzg5MjgsIGluaXQ9PG9wdGltaXplZCBvdXQ+LCBmaW5pPTxv cHRpbWl6ZWQgb3V0PiwgcnRsZF9maW5pPTxvcHRpbWl6ZWQgb3V0PiwgCiAgICBzdGFja19lbmQ9 MHg3ZmZmNWIzYzg5MTgpIGF0IGxpYmMtc3RhcnQuYzoyODkKIzI1IDB4MDAwMDAwMDAwMDQwMGJm OSBpbiBfc3RhcnQgKCkKRGV0YWNoaW5nIGZyb20gcHJvZ3JhbTogL3Vzci9iaW4va3dpbl94MTEs IHByb2Nlc3MgNDA0MAo=