[Haruna] [Bug 481445] New: Please add stream recording
https://bugs.kde.org/show_bug.cgi?id=481445 Bug ID: 481445 Summary: Please add stream recording Classification: Applications Product: Haruna Version: 0.12.3 Platform: Debian testing OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: ada...@proton.me Target Milestone: --- SUMMARY ** There is no capability to record live stream, which is present in mpv with option '--record-stream'. I'm fairly certain this appeals to most users that play streams. ** SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.27.10 -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 476852] New: Taskbar is almost completely transparent regardless of system theme
https://bugs.kde.org/show_bug.cgi?id=476852 Bug ID: 476852 Summary: Taskbar is almost completely transparent regardless of system theme Classification: Applications Product: kstars Version: 3.6.7 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: blake.brow...@yahoo.com Target Milestone: --- Created attachment 163056 --> https://bugs.kde.org/attachment.cgi?id=163056=edit Image showing issue SUMMARY Taskbar is transparent and makes parts of the program difficult to read when not in front of a dark, or blank background SOFTWARE/OS VERSIONS Linux/KDE Plasma: EndeavorOS KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456868] Use A Different Window Manager With Wayland
https://bugs.kde.org/show_bug.cgi?id=456868 --- Comment #2 from bl...@volian.org --- (In reply to David Edmundson from comment #1) > You can right now the same way one can replace kwin_x11. > > A lot will be broken there are more critical components that are desktop > specific on wayland than on X11 as they are not considered part of the core > protocol. Things like listing running applications in the taskmanager to > name just one aspect of many. This is not set to change. Thanks for the quick response. Just to be clear I tried with KDEWM environment variable and it just loads Kwin as normal, but in X11 will load whatever I'd like. Should I be using the Systemd method on something like the arch wiki? If that's the case I am guessing I'll have to wait for KDE to update in Debian Sid to 5.25 correct? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456868] New: Use A Different Window Manager With Wayland
https://bugs.kde.org/show_bug.cgi?id=456868 Bug ID: 456868 Summary: Use A Different Window Manager With Wayland Product: kwin Version: 5.24.5 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: bl...@volian.org Target Milestone: --- SUMMARY I apologize if this is the wrong place for this. I was unaware of where to put it but Kwin seems like a decent place. I have used KDE with i3 as the WM for quite some time. I have been testing some Wayland Compositor/WM and it seems like I'm not able to replace KWin in the same way. From what I understand this is likely due to the differences between how X11 functions and Wayland. I've done a fair bit of research through the source, and it seems to me this might be because under X11 Plasma starts Kwin, but due to the way Wayland operations, Kwin starts plasma? I'm not super privy to the inner workings of KDE, Wayland, and Kwin. I think this feature would be cool to have as I'd like to try to get Hyprland working with it. Also My apologies if there is already a way, I was just unable to find how to do it if it exists. I'm somewhat comfortable with C++ so I would be willing to help contribute to this feature if it doesn't already exist. I would just need someone to point me in the right direction as I don't have much knowledge on the Source code. I would also be okay with just a way to script start this configuration. For example make a `start-kde.sh` that will first start the Wayland Compositor and then load the needed components of KDE. I had attempted this but am unable to get this to work smoothly. I'm thinking this method would need layershell, maybe, I am unsure. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Sid KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION I specifically would like to make Hyprland work with KDE, but considering that it is in such early development Sway may be a better test subject to consider the feature complete. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442659] GTK3 Window decoration assets generated by kde-gtk-config are now all blank with Breeze window decoration
https://bugs.kde.org/show_bug.cgi?id=442659 Ash Blake changed: What|Removed |Added Latest Commit||https://invent.kde.org/plas ||ma/kde-gtk-config/commit/c1 ||0dff60289e8aa7b1989c49280b5 ||5711daaf14e Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Ash Blake --- Git commit c10dff60289e8aa7b1989c49280b55711daaf14e by Ash Blake. Committed on 02/10/2021 at 17:09. Pushed by ngraham into branch 'master'. kwin_bridge: Load DecorationButton without the "button" keyword Plugin keywords have been deprecated. Breeze and Oxygen no longer use the "button" keyword when registering their button plugins, so loading them now fails and blank assets get generated. Attempt loading DecorationButton without using the keyword, and if this fails, try the deprecated keyword like in the KWin commit 6f110bca. M +12 -2kded/kwin_bridge/dummydecorationbridge.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/c10dff60289e8aa7b1989c49280b55711daaf14e -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #27 from Ash Blake --- (In reply to Zamundaaa from comment #21) > The patch should "fix" that but I'd still like to find the actual source of > the problem. The stability has definitely improved with that patch, but some crashes still happened, way less often than before. Now I also applied the patches from MR 1467 and I can't trigger a crash anymore, and I don't see "DrmGpu::findWorkingCombination failed to find any functional combinations!" anymore in the logs. Looks like these two merge requests resolve this bug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #26 from Ash Blake --- Created attachment 141964 --> https://bugs.kde.org/attachment.cgi?id=141964=edit KWin DRM log messages from full Plasma session I got some of these errors in my wayland-session.log now. They're different, all of them are 'permission denied' -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #23 from Ash Blake --- Created attachment 141956 --> https://bugs.kde.org/attachment.cgi?id=141956=edit KWin DRM log from another machine (AMD GPU) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #22 from Ash Blake --- Created attachment 141955 --> https://bugs.kde.org/attachment.cgi?id=141955=edit KWin DRM log messages (In reply to Zamundaaa from comment #21) > You likely have some lines with something like "Atomic test for > CommitMode::Commit failed! Invalid Argument" and a bunch of numbers below it > in your ~/.local/share/sddm/wayland-session.log when KWin crashes. Could you > have a look at what the exact error messages are? For some reason they weren't in the log anymore, so I just ran in a TTY: $ (QT_LOGGING_RULES="kwin_wayland_drm.*=true" kwin_wayland 2>&1) > kwin_wayland_drm.log Are these fine or should I get logs from the full Plasma session? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #19 from Ash Blake --- (In reply to Ash Blake from comment #18) > and these multiple deletions may be normal Unfortunately, there is something wrong anyways even though it is not multiple deletion. Right before the crash, a pipeline that was involved in it got created and then deleted exactly three times in a row, so this is the same situation as previously but it turns out the destruction behaviour is actually normal. updateOutputs should not have received a deleted pipeline from findWorkingCombination though, so something is wrong here. Construction: $28 = (KWin::DrmPipeline * const) 0x56548a2aebd0 #0 KWin::DrmPipeline::DrmPipeline(KWin::DrmGpu*, KWin::DrmConnector*, KWin::DrmCrtc*, KWin::DrmPlane*) (this=this@entry=0x56548a2aebd0, gpu=0x565489679430, conn=0x565489e91be0, crtc=crtc@entry=0x5654896e4eb0, primaryPlane=primaryPlane@entry=0x5654896be1b0) at /home/ash/kde/src/kwin/src/plugins/platforms/drm/drm_pipeline.cpp:37 #1 0x7f0549d5e49c in operator()(KWin::DrmCrtc*, KWin::DrmPlane*) const (__closure=__closure@entry=0x7ffe8d5e8660, crtc=0x5654896e4eb0, primaryPlane=0x5654896be1b0) at /home/ash/kde/src/kwin/src/plugins/platforms/drm/drm_gpu.cpp:364 Destruction: $29 = (KWin::DrmPipeline * const) 0x56548a2aebd0 #0 KWin::DrmPipeline::~DrmPipeline() (this=0x56548a2aebd0, __in_chrg=) at /usr/include/c++/11.1.0/bits/atomic_base.h:479 #1 0x7f0549d5e99e in operator()(KWin::DrmCrtc*, KWin::DrmPlane*) const (__closure=__closure@entry=0x7ffe8d5e8660, crtc=, primaryPlane=0x7ffe8d5e85a8) at /home/ash/kde/src/kwin/src/plugins/platforms/drm/drm_gpu.cpp:373 Relevant lines from the segfault backtrace, with yet another exact point of crash: #0 QSharedPointer::deref(QtSharedPointer::ExternalRefCountData*) (dd=0x56540002) at /usr/include/qt/QtCore/qsharedpointer_impl.h:454 #1 QSharedPointer::deref() (this=) at /usr/include/qt/QtCore/qsharedpointer_impl.h:453 #2 QSharedPointer::~QSharedPointer() (this=, __in_chrg=) at /usr/include/qt/QtCore/qsharedpointer_impl.h:310 #3 QSharedPointer::operator=(QSharedPointer const&) (other=, other=..., this=0x56548a2aebf8) at /usr/include/qt/QtCore/qsharedpointer_impl.h:333 #4 KWin::DrmPipeline::present(QSharedPointer const&) (this=0x56548a2aebd0, buffer=...) at /home/ash/kde/src/kwin/src/plugins/platforms/drm/drm_pipeline.cpp:81 #5 0x7f0549d55bb8 in KWin::DrmOutput::present(QSharedPointer const&, QRegion) (this=this@entry=0x565489e97d50, buffer=..., damagedRegion=...) at /home/ash/kde/src/kwin/src/plugins/platforms/drm/drm_output.cpp:394 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #18 from Ash Blake --- (In reply to Ash Blake from comment #17) Nevermind, I totally forgot allocation could just happen at the same address after deleting something there and these multiple deletions may be normal. I'll redo it, also tracking construction this time. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 Ash Blake changed: What|Removed |Added Attachment #141922|0 |1 is obsolete|| --- Comment #17 from Ash Blake --- Created attachment 141950 --> https://bugs.kde.org/attachment.cgi?id=141950=edit Debugging session with both good and bad VT switches This is an annotated log from the debugging session with backtraces of each pipeline destruction, including the addresses of said pipelines. For convenience, you can also view it with basic formatting here: https://gist.github.com/telepathine/01bd060e5df3ece55f6b46bb63a78078 It features both the successful case and the failed one, which differs quite notably in the pipeline destruction department - one pipeline gets deleted three times, then that address happens to be reused as for some reason some DrmOutput still has it. This leads to a segfault originating from KWin::DrmPipeline::setSyncMode later on. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #16 from Ash Blake --- This crash is also quite unpredictable, sometimes I can switch a lot of times between two sessions with no crash, and sometimes it will crash on the first try. Usually if the crash already occurs in one of the sessions, it will then keep reoccuring whenever switching away from it and back. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #15 from Ash Blake --- (In reply to Zamundaaa from comment #14) > Sounds a lot like https://bugs.kde.org/show_bug.cgi?id=442677 It really does, but I already have the commit that fixed that bug in my KWin build. Seems like there's some other problem that causes the same crash on VT switches, and there's also this weird crash in KWin::DrmObject::getProp that happens sometimes too. If I notice crashes in some other places, I'll upload those backtraces too. The getProp crash case is particularly weird. At a quick glance it seems that the crtc in a pipeline could not suddenly end up null under normal circumstances, as there doesn't seem to be a method that changes a DrmPipeline's m_crtc after initialization. Maybe the memory for it was freed and used by something else, but something still used the pointer to the deleted pipeline? I guess a situation like this could cause all kinds of crashes in various places. I'll try setting up breakpoints on destructors of various drm-related objects and keeping track of the objects' addresses to compare them after a crash happens to check if that is the case. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873
--- Comment #13 from Ash Blake ---
And with the crash from the getProp call in KWin::DrmPipeline::setSyncMode,
m_crtc has been a null pointer in at least two backtraces
(gdb) p *m_pipeline
$2 = {
m_output = 0x5592ffd79a3b,
m_gpu = 0x5597a695a010,
m_connector = 0x18,
m_crtc = 0x0,
m_primaryPlane = 0x0,
m_primaryBuffer = {
value = 0x3ff0,
d = 0x3ff0
},
m_oldTestBuffer = {
value = 0x408e,
d = 0x0
},
m_legacyNeedsModeset = false,
m_cursor = {
pos = {
xp = 0,
yp = 1072693248
},
hotspot = {
xp = 0,
yp = 1083047936
},
buffer = {
value = 0x403d,
d = 0x408e0800
},
dirtyBo = false,
dirtyPos = false
},
m_allObjects = {
d = 0x0
},
m_formats = {
d = 0x403d
},
m_lastFlags = 0
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873
--- Comment #12 from Ash Blake ---
(In reply to Ash Blake from comment #11)
> Created attachment 141939 [details]
The contents of m_gpu look odd - cursor size of 262147x458757, insanely high
file descriptor and some suspicious looking addresses.
It seems like DrmGpu got destroyed, but it still got used somehow.
(gdb) p *m_gpu
$11 = {
...
m_backend = 0x7000700060007,
m_eglBackend = {
wp = {
d = 0x7000600070005,
value = 0x6000700020007
}
},
m_devNode = {
d = 0x3000100020003
},
m_cursorSize = {
wd = 262147,
ht = 458757
},
m_fd = 262145,
m_deviceId = 1970354902204420,
m_atomicModeSetting = 6,
m_useEglStreams = false,
m_gbmDevice = 0x7000100050007,
m_eglDisplay = 0x700070003,
m_presentationClock = 327687,
m_socketNotifier = 0x7000700070007,
m_addFB2ModifiersSupported = 5,
m_planes = {
d = 0x7000100030007
},
m_crtcs = {
d = 0x556bab5abab0
},
m_connectors = {
d = 0x556bab6581b0
},
m_pipelines = {
d = 0x556bab56b5b0
},
m_drmOutputs = {
d = 0x556babd27990
},
m_outputs = {
d = 0x556babe865c0
},
m_leaseOutputs = {
d = 0x7f08040086f0
},
m_leaseDevice = 0x556bab56b330
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #11 from Ash Blake --- Created attachment 141939 --> https://bugs.kde.org/attachment.cgi?id=141939=edit Another backtrace, crash in DrmPipeline::populateAtomicValues Another crash on VT switch. obj pointed to an unreadable location. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438010] kwin crashes when clicking on MPV with a pen
https://bugs.kde.org/show_bug.cgi?id=438010 Ash Blake changed: What|Removed |Added Latest Commit||https://invent.kde.org/plas ||ma/kwin/commit/242de4373706 ||324696a9bfe48b1ac9e2f7e2caa ||2 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Ash Blake --- Git commit 242de4373706324696a9bfe48b1ac9e2f7e2caa2 by Ash Blake. Committed on 26/09/2021 at 09:02. Pushed by apol into branch 'master'. tablet: Check if client is supported before sending tool button M +3-0src/input.cpp https://invent.kde.org/plasma/kwin/commit/242de4373706324696a9bfe48b1ac9e2f7e2caa2 -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 442852] Fast user switching is broken since 5.23 beta
https://bugs.kde.org/show_bug.cgi?id=442852 --- Comment #4 from Ash Blake --- Proposed fix that also fixes the original warnings: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1081 -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 442852] Fast user switching is broken since 5.23 beta
https://bugs.kde.org/show_bug.cgi?id=442852 Ash Blake changed: What|Removed |Added CC||telepath...@tutanota.com --- Comment #2 from Ash Blake --- This is a regression from commit 714ce4045e0cbbba1d440b2fcb6f547f2680799f in plasma-workspace. The property m which exposed the model has been removed from UserDelegate, but it wasn't unused. In SessionManagementScreen, userListCurrentModelData was supposed to be pointing at userListView.currentItem.m which is now undefined. The only usage of userListCurrentModelData is in LockScreenUi.qml:436, where the TypeError occurs. Reverting that commit makes user switching work again. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #9 from Ash Blake --- Created attachment 141923 --> https://bugs.kde.org/attachment.cgi?id=141923=edit Screen recording showing the problem -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 --- Comment #8 from Ash Blake --- Created attachment 141922 --> https://bugs.kde.org/attachment.cgi?id=141922=edit Backtrace (git master) The old user's and new user's backtraces look the same. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439873] Switching users isn't working on Wayland
https://bugs.kde.org/show_bug.cgi?id=439873 Ash Blake changed: What|Removed |Added CC||telepath...@tutanota.com --- Comment #7 from Ash Blake --- (In reply to Nate Graham from comment #4) > On Wayland, I get to the login screen, but logging into the other user > fails; after I enter the other user's password and click the login button I > get kicked back to the lock screen of my existing session. This works for me, the new user's session starts every time. However, either the old user's session or the new user's session will crash when switching. I have kwin_wayland coredumps from both users and I'll upload the backtraces soon. (In reply to Nate Graham from comment #6) > Maybe the bug is that it didn't succeed in logging *me* into that user? (In reply to Nate Graham from comment #5) > ~/kde/usr/bin/ksmserver It probably failed to log in as the other user because you tried to run the same development KDE session, and the other user wouldn't be able to read and execute anything in your home directory. startplasma-wayland won't run, so the new user will only be running the systemd user daemon and whatever stuff it started. Give konqi execute access to your home directory so he can cd into it, and make him the group of $HOME/kde so he can read and execute things in there: $ setfacl -m u:konqi:x $HOME $ chown -R $USER:konqi $HOME/kde -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438010] kwin crashes when clicking on MPV with a pen
https://bugs.kde.org/show_bug.cgi?id=438010 --- Comment #13 from Ash Blake --- This happened because there was no check if the resource is valid before calling sendButton. I created a merge request: https://invent.kde.org/plasma/kwin/-/merge_requests/1461 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438010] kwin crashes when clicking on MPV with a pen
https://bugs.kde.org/show_bug.cgi?id=438010 --- Comment #12 from Ash Blake --- I attached GDB to KWin and checked where the null pointer came from in TabletToolV2InterfacePrivate::targetResource(). m_surface was not null, but later resourceMap().value(*client) returned 0x0. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438010] kwin crashes when clicking on MPV with a pen
https://bugs.kde.org/show_bug.cgi?id=438010 --- Comment #11 from Ash Blake --- I rebuilt libwayland with debug symbols. Resource was a null pointer: #0 wl_resource_post_event (resource=0x0, opcode=17) at ../wayland-1.19.0/src/wayland-server.c:248 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438010] kwin crashes when clicking on MPV with a pen
https://bugs.kde.org/show_bug.cgi?id=438010 Ash Blake changed: What|Removed |Added CC||telepath...@tutanota.com --- Comment #10 from Ash Blake --- Created attachment 141879 --> https://bugs.kde.org/attachment.cgi?id=141879=edit Backtrace from current git master I can reproduce this as well, with a Huion tablet. I don't know how to make GDB show line numbers for functions called via std::bind, so here's the disassembly of the part around frame #1: ... 0x7f0e976df57f <+95>:mov%ebp,%esi 0x7f0e976df581 <+97>:call 0x7f0e97625150 <_ZN14KWaylandServer21TabletToolV2Interface10sendButtonEjb@plt> => 0x7f0e976df586 <+102>: add$0x8,%rsp 0x7f0e976df58a <+106>: mov$0x1,%eax 0x7f0e976df58f <+111>: pop%rbx ... Looks like this happened in kwin/src/input.cpp:1862 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #37 from Ash Blake --- (In reply to Vlad Zahorodnii from comment #36) > Created attachment 141876 [details] > Potential solution (untested) > > If you apply the attached patch, does the issue go away? Yes, I just tested it with 1000 windows and there are no leaked descriptors. In the strace output, there are now close() calls for every FD. When using a Jetbrains IDE everything works fine as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #34 from Ash Blake --- (In reply to Vlad Zahorodnii from comment #33) > Thanks for the great analysis, Ash! This is definitely very strange. At > quick glance, I don't see how file descriptors can be leaked in kwin. Well, it doesn't seem to be KWin that leaks them. It happens along the way in libwayland. This one is perhaps more useful - same test as above, but only one window gets created with a 16ms lifetime. It appears this is actually enough to induce the bug, and patterns are more visible. close(4071) = 0 recvmsg(44,...,cmsg_data=[4071],...) = 152 close(4071) = 0 recvmsg(44,...,cmsg_data=[4034],...) = 152 close(4034) = 0 recvmsg(48,...,cmsg_data=[4034, 4035],...) = 16 recvmsg(44,...,cmsg_data=[4071],...) = 152 close(4071) = 0 recvmsg(48,...,cmsg_data=[4071, 4079],...) = 16 recvmsg(44,...,cmsg_data=[4150],...) = 152 close(4150) = 0 recvmsg(48,...,cmsg_data=[4150, 4608],...) = 16 recvmsg(44,...,cmsg_data=[4610],...) = 152 close(4610) = 0 recvmsg(48,...,cmsg_data=[4610, 4611],...) = 16 recvmsg(44,...,cmsg_data=[4612],...) = 152 close(4612) = 0 recvmsg(48,...,cmsg_data=[4612, 4615],...) = 16 recvmsg(44,...,cmsg_data=[4618],...) = 152 close(4618) = 0 recvmsg(48,...,cmsg_data=[4618, 4619],...) = 16 recvmsg(44,...,cmsg_data=[4620],...) = 152 close(4620) = 0 recvmsg(48,...,cmsg_data=[4620, 4621],...) = 16 ^CThese descriptors were left open: 4034, 4035, 4071, 4079, 4150, 4608, 4610, 4611, 4612, 4615, 4618, 4619, 4620, 4621 KWin does close every descriptor it receives. However, sometimes the process does not receive one descriptor, but two - and KWin itself is not aware of the second one, nor is it supposed to. This is the bug-free scenario (100ms lifetime): close(4622) = 0 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 recvmsg(44,...,cmsg_data=[4622],...) = 152 close(4622) = 0 recvmsg(48,...,cmsg_data=[4622, 5710],...) = 16 ^CThese descriptors were left open: 4622, 5710 (And those two descriptors got closed shortly after) Here the same thing happens, however things happen slowly enough so that the descriptor can get reused, hence the fd amount is not rising. It seems like this is not KWin's fault, but it's Wayland that is doing something weird when marshaling those descriptors. org_kde_plasma_window_get_icon is supposed to accept one file descriptor, and plasmashell does give it exactly one descriptor. Things get messed up along the way, and this is not an issue anywhere in the KDE code. While researching the topic of SCM_RIGHTS, I stumbled upon this link: https://gist.github.com/kentonv/bc7592af98c68ba2738f4436920868dc This part sounds like it could be a problem here: > However, as always, recvmsg() calls on the receiving end don't necessarily > map 1:1 to sendmsg() calls. Messages can be coalesced or split. Sounds like things can get mixed up when messages are getting sent fast enough. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #32 from Ash Blake --- Created attachment 141875 --> https://bugs.kde.org/attachment.cgi?id=141875=edit A Python script that parses strace output for FD information I wrote a script to parse strace output and abbreviate it, displaying only close() calls and recvmsg() calls, but filtered by cmsg_type=SCM_RIGHTS and abbreviated so that only the cmsg_data part containing newly received file descriptors is visible. After terminating the script with Ctrl+C, it will display all the file descriptors that have been received by the KWin process, but not closed. This is the output in a bug-free situation (the reproducing program was ran with a burst size of 20 and window lifetime of 100ms, which does not trigger the bug) $ sudo strace -e trace=recvmsg,close -p `pidof kwin_wayland` 2>&1 | python process_strace.py close(5670) = 0 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670],...) = 84 recvmsg(48,...,cmsg_data=[5670],...) = 8 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 recvmsg(44,...,cmsg_data=[5670],...) = 152 close(5670) = 0 recvmsg(48,...,cmsg_data=[5670, 5675],...) = 16 ^CThese descriptors were left open: 5670, 5675 The mentioned descriptors have been however closed shortly after. This is the output with also 20 windows, but a lifetime of 16ms: $ sudo strace -e trace=recvmsg,close -p `pidof kwin_wayland` 2>&1 | python process_strace.py recvmsg(44,...,cmsg_data=[5696],...) = 152 close(5696) = 0 recvmsg(48,...,cmsg_data=[5696, 5697],...) = 16 recvmsg(44,...,cmsg_data=[5696],...) = 152 close(5696) = 0 recvmsg(48,...,cmsg_data=[5696, 5697],...) = 16 recvmsg(44,...,cmsg_data=[5700],...) = 152 close(5700) = 0 recvmsg(48,...,cmsg_data=[5700, 5701],...) = 16 recvmsg(44,...,cmsg_data=[5700],...) = 152 close(5700) = 0 recvmsg(44,...,cmsg_data=[5700],...) = 152 close(5700) = 0 recvmsg(48,...,cmsg_data=[5700, 5701],...) = 16 recvmsg(44,...,cmsg_data=[5702],...) = 152 close(5702) =
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #31 from Ash Blake --- (In reply to Ash Blake from comment #30) > break PlasmaWindow::Private::iconChangedCallback > commands > silent > printf "hello\n" > end Oops, forgot a continue there. break PlasmaWindow::Private::iconChangedCallback commands silent printf "hello\n" cont end -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #30 from Ash Blake --- > The short burst length of 2 was motivated by observing the popup windows > flicker without any content sometimes, before the actual popup appeared. Post scriptum: in fact, when GDB is attached to plasmashell in non-stop mode and a breakpoint is set in PlasmaWindow::Private::iconChangedCallback with commands specified so that it does not pause execution, for instance: break PlasmaWindow::Private::iconChangedCallback commands silent printf "hello\n" end , we can observe the string "hello" appearing twice when a single popup window appears, and also twice when a single popup disappears, suggesting there was another window that appeared for several miliseconds before getting destroyed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #29 from Ash Blake --- Created attachment 141874 --> https://bugs.kde.org/attachment.cgi?id=141874=edit A C program that reproduces the bug I figured out which behaviour of the Jetbrains IDEs causes the bug to occur and I wrote a program that replicates it, so the bug can be reproduced reliably and without the need to install any software. This program will repeatedly create a specified amount of windows, waiting some time before destroying the current window and creating the next one. After that, it will wait a specified amount of time and repeat the whole thing. The amount of windows and the time constants are optional program arguments. The default settings are supposed to replicate a realistic scenario that could happen during the IDE usage. They are as follows: - (arg1) burst size: 2 - (arg2) window lifetime (ms): 16 - (arg3) post-burst wait time (ms): 3000 The short burst length of 2 was motivated by observing the popup windows flicker without any content sometimes, before the actual popup appeared. On my machine, this burst size and window lifetime causes the KWin's file descriptor count to increase by 3 each repetition, same as when a popup is opened normally in a Jetbrains IDE. Of course, if such settings do not cause bug reproduction in your environment, start by increasing the burst size. If the bug still isn't reproduced with a high amount of created windows, start decreasing the window lifetime. Some observations: 1. If the window lifetime is large enough to reliably observe the window's icon appearing on the taskbar, this bug does not occur. On my machine, a window lifetime of 60ms is the minimum one that does not cause KWin's file descriptor amount to notably rise at any point in time, even with a burst size of 9 windows. 2. Window lifetimes less or equal to 4ms will cause KWin to lag, up to the point of a complete freeze (which resolves during the wait time). Of course this is a terribly unrealistic scenario and no application would ever do that, but watch out when testing. Compilation: $ gcc reproduce_438097.c -lX11 -o reproduce_438097 Usage $ ./reproduce_438097 [burst size] [window lifetime] [post-burst wait time] -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #27 from Ash Blake --- The file descriptor flood comes from PlasmaWindow::Private::iconChangedCallback (kwayland/src/client/plasmawindowmanagement.cpp:655, master branch). This can be easily verified by catching pipe2 in the plasmashell process - the backtrace will show this function. Occurences of pipe2 in the strace output for plasmashell correlate with the amount of KWin's file descriptors. After calling the org_kde_plasma_window_get_icon interface, the FDs get copied over to KWin's process using Wayland's proxy magic, which seems to be using the sendmsg and recvmsg syscalls with SCM_RIGHTS ancillary messages, which enable passing open descriptors between processes. The function which gets called after marshaling the FDs by the Wayland's proxy thingy is PlasmaWindowInterfacePrivate::org_kde_plasma_window_get_icon (kwayland-server/src/server/plasmawindowmanagement_interface.cpp:437) Things get really odd now. Both of those functions look fine to me - it doesn't look like either the server side or the client side would leave a descriptor open after finishing its work. I walked through both the icon read and write in GDB, and everything was seemingly handled correctly for the cases I observed. Despite no errors, many of these supposedly closed descriptors did still appear in /proc/$KWIN_PID/fd. I have no idea what could be going on. For a test, I replaced org_kde_plasma_window_get_icon with a function that only calls close(fd). Somehow, the KWin process still had rapidly increasing amounts of FDs, even though this time it was just supposed to close them ASAP. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #25 from Ash Blake --- This is pretty weird. I just tried running IDEA in KWin only, started from a TTY. The file descriptor amount does not skyrocket, and everything is stable. It also works fine in nested KWin inside a Plasma session. Seems like some other Plasma component is causing KWin to leak file descriptors. I tried killing various combinations of Plasma processes, and it looks like killing plasmashell, xdg-desktop-portal, and xdg-desktop-portal-kde helps. KWin does not leak file descriptors anymore, and it does not crash. I guess plasmashell and xdg-desktop-portal-kde could be trying to read some information about the popup window, but failure might not be handled correctly and new pipe descriptors get created over and over during each retry attempt until KWin crashes. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #24 from Ash Blake --- Created attachment 141808 --> https://bugs.kde.org/attachment.cgi?id=141808=edit Timelapse of lsof count, after increasing the open fd limit to 8192 This shows the test running for much longer (5 minutes), after max file descriptors for KWin were increased. It could run for a bit longer as fds were not exhausted yet. The interesting thing is how again plasmashell crashed early. This proves that things just go crazy after the file descriptor limit is exhausted, and there is no direct problem in AnimationEffect. KWin crashes in that place, but the real problem is the file descriptor leak and all kinds of chaotic behaviour it can cause. Are there any logs I can provide to help debug this issue? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #23 from Ash Blake --- Created attachment 141807 --> https://bugs.kde.org/attachment.cgi?id=141807=edit Outputs of lsof -p $KWIN_PID taken every second, from the test start to KWin crash Additional logs for #22 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #22 from Ash Blake --- Created attachment 141806 --> https://bugs.kde.org/attachment.cgi?id=141806=edit Screencast demonstrating the rising amount of open files by KWin Regarding the previous error about too many open files: This screencast shows the count of open files during the popup window test. It is steadily rising, and does not decrease after stopping the test, nor after quitting IntelliJ IDEA completely. If the test gets stopped at, say, 1000 open fds, after resuming it a crash happens pretty quickly. The screencast ends when KWin crashes, which happens after around 1400 file descriptors get opened. In the following message I will attach a .tar.gz archive containing the output of lsof -p $KWIN_PID taken every second since starting the test. The offending descriptors are mostly pipes. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #21 from Ash Blake --- This time KWin didn't crash completely, but entered a weird state. Plasmashell stopped working, but most of the applications were still running, including IDEA. I stopped the test, because if it continued it would most likely result in a crash. It is not possible to restart plasmashell right now, nor launch any new program. These errors appeared in wayland-session.log when plasmashell crashed: file descriptor expected, object (308), message get_icon(7h) error in client communication (pid 496515) QMetaProperty::read: Unable to handle unregistered datatype 'KWin::SessionState' for property 'KWin::EffectsHandlerImpl::sessionState' wl_display@1: error 1: invalid arguments for org_kde_plasma_window@308.get_icon This appeared in terminal when trying to restart plasmashell: wl_display@1: error 1: invalid arguments for wl_shm@81.create_pool The Wayland connection experienced a fatal error: Invalid argument And around the same time, this appeared in wayland-session.log: file descriptor expected, object (81), message create_pool(nhi) error in client communication (pid 498931) QMetaProperty::read: Unable to handle unregistered datatype 'KWin::SessionState' for property 'KWin::EffectsHandlerImpl::sessionState' While typing this message, Firefox and a bunch of other things have crashed. The following got logged to wayland-session.log: file descriptor expected, object (30), message add(hu) error in client communication (pid 499807) wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params...@30.add [266 00:35:02.451499] [glfw error 65544]: Wayland: fatal display error: Invalid argument file descriptor expected, object (30), message add(hu) error in client communication (pid 499827) wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params...@30.add [266 00:35:06.638735] [glfw error 65544]: Wayland: fatal display error: Invalid argument file descriptor expected, object (30), message add(hu) error in client communication (pid 499851) file descriptor expected, object (30), message add(hu) error in client communication (pid 499907) file descriptor expected, object (30), message add(hu) error in client communication (pid 499954) wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params...@30.add [266 00:35:18.863341] [glfw error 65544]: Wayland: fatal display error: Invalid argument file descriptor expected, object (63), message add(hu) error in client communication (pid 499370) file descriptor expected, object (7), message create_pool(nhi) error in client communication (pid 500198) file descriptor expected, object (7), message create_pool(nhi) error in client communication (pid 500233) kwin_core: Could not trust "/usr/bin/plasma-browser-integration-host" sha "" "" This is followed by 6649 repetitions of this line: failed to accept: Too many open files -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #20 from Ash Blake --- This short script can be used to trigger a crash: #!/bin/bash win_id=$(sort <(xdotool search --name "Content window") <(xdotool search --class "jetbrains-idea") | uniq -d) sleep 10 while : do xdotool key --window $win_id period sleep 0.1 xdotool key --window $win_id BackSpace done After opening a project in IDEA and typing something like 'System' in a line, run the script and switch back to the IntelliJ IDEA window. For me, with automated keymashing it takes 420-450 popups to crash the Wayland session. On X11, it's completely stable even though the window identifiers also rapidly increase. I terminated the test after around 1000 popups. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #19 from Ash Blake --- Created attachment 141801 --> https://bugs.kde.org/attachment.cgi?id=141801=edit Code completion popup window IDs in the debug console Update: It appears that the crashes are highly correlated with the amount of popup windows opened in total during a session of coding. Each new popup causes an increment in the hexadecimal window ID and the window's caption (win1, win2, win3, etc.) seen in the KWin debug console. For me, the crash happens somewhere around win300. I reproduced the crash three times in a row by typing a name of some object then repeatedly mashing dot and backspace keys, so that the autocompletion popups flash rapidly. Because the window IDs increase so quickly and the problem happens around a similar amount of open popup windows, could this be some sort of overflow problem? Maybe this could explain the weird corruption described in my previous two comments, where some fields of the EffectWindow even looked sensible, but the vtable located at the beginning of memory allocated for the EffectWindow was completely ruined. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 Ash Blake changed: What|Removed |Added Version|5.22.1 |5.22.90 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #18 from Ash Blake --- I didn't get a crash so far, but I revisited the previous coredump, as it seems weird that the EffectWindow was at least a bit intact this time. Disassembly of the current instruction and the one before it: 0x7fb16c02e4c2 <...postPaintScreenEv+1682> mov(%rdi),%rax > 0x7fb16c02e4c5 <...postPaintScreenEv+1685> call *0x90(%rax) The RDI register contained the address of the EffectWindow, same as in entry.key EffectWindow::addLayerRepaint is virtual, so the address of the actual function EffectWindowImpl::addLayerRepaint has to be read from the vtable. (In this case) the first few bytes of EffectWindow should contain a vtable ptr, which is then read into RAX by 'mov (%rdi),%rax'. The EffectWindowImpl::addLayerRepaint function pointer is then expected to exist at RAX + 0x90. It looks like the vtable pointer points to an invalid location: (gdb) p/x $rax $23 = 0x55f806f2e (gdb) x/x $rax 0x55f806f2e:Cannot access memory at address 0x55f806f2e And vtable+0x90 is also unreadable: (gdb) x/x $rax+0x90 0x55f806fbe:Cannot access memory at address 0x55f806fbe In the coredump from yesterday, the situation is the same: 0x7f9fafd984c2 <...postPaintScreenEv+1682> mov(%rdi),%rax > 0x7f9fafd984c5 <...postPaintScreenEv+1685> call *0x90(%rax) (gdb) p/x $rax $1 = 0x55f06b86305a (gdb) x/x $rax 0x55f06b86305a: Cannot access memory at address 0x55f06b86305a (gdb) x/x $rax+0x90 0x55f06b8630ea: Cannot access memory at address 0x55f06b8630ea Yesterday the EffectWindow was destroyed completely, and the member variables looked pretty much random. In today's crash it seems like the EffectWindow was in the process of getting deleted, as some of the member variables looked intact. The vtable however already got corrupted, which made the call result in a segfault. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097
--- Comment #17 from Ash Blake ---
This time, however, it seems EffectWindow was not completely destroyed.
Unlike in the last crash, the data inside EffectWindow is not complete garbage.
For instance, the addresses in toplevel and EffectWindow::Private pointers look
more sensible, dataMap contains valid pointers to QHashData::shared_null, and
x11Client is true.
(gdb) p *(EffectWindowImpl*)(entry.i->key)
$10 = {
= {
= {},
members of KWin::EffectWindow:
static staticMetaObject = {
...
},
d = {
d = 0x55f806b0fa80
}
},
members of KWin::EffectWindowImpl:
static staticMetaObject = {
...
},
toplevel = 0x55f80706bcf0,
sw = 0x0,
dataMap = {
{
d = 0x7fb16aa6e5c0 ,
e = 0x7fb16aa6e5c0
}
},
managed = true,
waylandClient = false,
x11Client = true
}
Inspection of toplevel:
(gdb) p *(Toplevel*)$ew.toplevel
{
= {},
members of KWin::Toplevel:
static staticMetaObject = {
...
},
m_frameGeometry = {
x1 = 640,
y1 = 547,
x2 = 1030,
y2 = 654
},
m_clientGeometry = {
x1 = 640,
y1 = 547,
x2 = 1030,
y2 = 654
},
m_bufferGeometry = {
x1 = 640,
y1 = 547,
x2 = 1030,
y2 = 654
},
m_visual = 59,
bit_depth = 24,
info = 0x55f806a48670,
ready_for_painting = true,
m_internalFBO = {
value = 0x0,
d = 0x0
},
m_internalImage = ,
m_internalId = {
data1 = 3760014763,
data2 = 36097,
data3 = 19896,
data4 = "\246\035\236h\342\216t\223"
},
m_client = {
m_window = 18875715,
m_destroy = false,
m_logicGeometry = {
x1 = 0,
y1 = 0,
x2 = -1,
y2 = -1
}
},
is_shape = false,
effect_window = 0x0,
m_shadow = 0x0,
resource_name = {
d = 0x55f806b26260
},
resource_class = {
d = 0x55f805f58430
},
m_clientMachine = 0x55f806442ca0,
m_wmClientLeader = 18874376,
opaque_region = {
d = 0x7fb16b3071e0
},
m_shapeRegion = {
d = 0x55f806cc0a30
},
m_shapeRegionIsValid = true,
m_output = 0x55f805b4d020,
m_skipCloseAnimation = false,
m_surfaceId = 0,
m_surface = 0x0,
m_screenScale = 1,
m_opacity = 1,
m_stackingOrder = 5
}
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097 --- Comment #16 from Ash Blake --- Okay, it crashed again. The backtrace looks the same as the last one. The crash is again in kwin4_effect_fade: (gdb) p this $3 = (KWin::ScriptedEffect * const) 0x55f805fa1440 (gdb) set $data_start = (char*)this->m_effectName->d + this->m_effectName->d->offset (gdb) set $len = this->m_effectName->d->size (gdb) set $i = 0 (gdb) while $i < 2*$len >printf "%c", *($data_start + $i) >set $i = $i + 2 >end kwin4_effect_fade I'll test the Glide window open/close animation now, as it's a native one and may behave differently. I suppose there's no point in testing Scale as it's a scripted effect and it will probably have the same problem Fade has. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097
--- Comment #15 from Ash Blake ---
Additional information about that EffectWindow, as I forgot it's actually an
instance of EffectWindowImpl and didn't dump members of the latter.
Both the toplevel and sw pointers lead to inaccessible memory addresses.
(gdb) p *(KWin::EffectWindowImpl *)entry.i->key
...
members of KWin::EffectWindowImpl:
static staticMetaObject = {
d = {
superdata = {
direct = 0x7f9fafdb2900
},
stringdata = 0x7f9fb01ae880 ,
data = 0x7f9fb01ae840 ,
static_metacall = 0x7f9faff9e1a0
,
relatedMetaObjects = 0x0,
extradata = 0x0
}
},
toplevel = 0x239043d,
sw = 0x20a0282,
dataMap = {
{
d = 0x239043d,
e = 0x239043d
}
},
managed = false,
waylandClient = false,
x11Client = false
...
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 438097] [AnimationEffect] kwin_wayland sometimes crashes when xwayland tries to display a popup
https://bugs.kde.org/show_bug.cgi?id=438097
Ash Blake changed:
What|Removed |Added
CC||telepath...@tutanota.com
--- Comment #14 from Ash Blake ---
Created attachment 141780
--> https://bugs.kde.org/attachment.cgi?id=141780=edit
Backtrace from 5.22.90
This is a backtrace from Plasma 5.22.90 from the Arch Linux kde-unstable repo,
with the KWin package rebuilt from source to provide debug symbols.
The crash happened randomly while using Jetbrains IntelliJ IDEA.
My effects setup is mostly default, I only enabled the new Overview effect.
Effect list:
- kwin4_effect_windowaperture
- kwin4_effect_squash
- kwin4_effect_sessionquit
- kwin4_effect_morphingpopups
- kwin4_effect_maximize
- kwin4_effect_logout
- kwin4_effect_login
- kwin4_effect_fullscreen
- kwin4_effect_frozenapp
- kwin4_effect_fadingpopups
- kwin4_effect_fade
- kwin4_effect_dialogparent
- zoom
- slidingpopups
- slide
- screenshot
- desktopgrid
- colorpicker
- presentwindows
- overview
- highlightwindow
- blur
- contrast
- startupfeedback
- screenedge
- screentransform
- kscreen
I analysed the core dump with GDB - the crash happened in kwin4_effect_fade.
Redacted log from the gdb session (at the innermost stack frame):
(gdb) set print pretty on
(gdb) set print object on
(gdb) p *this
$1 = (KWin::ScriptedEffect) {
...
members of KWin::ScriptedEffect:
...
m_effectName = {
d = 0x55f534b8f590
},
...
}
(gdb) p this->m_effectName->d
$3 = (QString::Data *) 0x55f534b8f590
(gdb) set $data_start = (char*)this->m_effectName->d +
this->m_effectName->d->offset
(gdb) set $len = this->m_effectName->d->size
(gdb) set $i = 0
(gdb) while $i < 2*$len
>printf "%c", *($data_start + $i)
>set $i = $i + 2
>end
kwin4_effect_fade
When the crash happens again, I'll check if it was the same effect.
If so, I'll disable it and test some more.
Some information about that EffectWindow pointer:
(gdb) p *(entry.i->key)
$45 = {
= {},
members of KWin::EffectWindow:
static staticMetaObject = {
d = {
superdata = {
direct = 0x7f9fae97c740
},
stringdata = 0x7f9fafda5ae0 ,
data = 0x7f9fafda55a0 ,
static_metacall = 0x7f9fafd8ced0
,
relatedMetaObjects = 0x0,
extradata = 0x0
}
},
d = {
d = 0x20a0282
}
}
(gdb) p &(entry.i->key->d)
$33 = (QScopedPointer > *) 0x55f53571a4d0
(gdb) p entry.i->key->d.d
$34 = (KWin::EffectWindow::Private *) 0x20a0282
(gdb) p *(entry.i->key->d.d)
Cannot access memory at address 0x20a0282
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 416005] Crash while adjusting monitor layout and refresh rate in kscreen
https://bugs.kde.org/show_bug.cgi?id=416005 blake changed: What|Removed |Added CC||blakesommer...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 416005] Crash while adjusting monitor layout and refresh rate in kscreen
https://bugs.kde.org/show_bug.cgi?id=416005 --- Comment #13 from blake --- Created attachment 133396 --> https://bugs.kde.org/attachment.cgi?id=133396=edit New crash information added by DrKonqi systemsettings5 (5.18.5) using Qt 5.14.2 - What I was doing when the application crashed: Changing refresh rates and enabling a second tb3 monitor. Kscreen crashes and monitor does not enable. -- Backtrace (Reduced): #4 0x7f38d945ac44 in KScreen::Mode::size() const () from /lib64/libKF5Screen.so.7 #5 0x7f38d94f2ba2 in OutputModel::setRefreshRate(int, int) () from /usr/lib64/qt5/plugins/kcms/kcm_kscreen.so #6 0x7f3905b2312d in QQmlDMCachedModelData::metaCall(QMetaObject::Call, int, void**) () from /lib64/libQt5QmlModels.so.5 #7 0x7f3907005f70 in QQmlPropertyPrivate::write(QObject*, QQmlPropertyData const&, QVariant const&, QQmlContextData*, QFlags) () from /lib64/libQt5Qml.so.5 #8 0x7f3906f3d8cb in QV4::QObjectWrapper::setProperty(QV4::ExecutionEngine*, QObject*, QQmlPropertyData*, QV4::Value const&) () from /lib64/libQt5Qml.so.5 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 417117] New: Plasma Crash to Black Screen After Sticky Note Creation
https://bugs.kde.org/show_bug.cgi?id=417117 Bug ID: 417117 Summary: Plasma Crash to Black Screen After Sticky Note Creation Product: plasmashell Version: 5.17.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: blakeg...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 Application: plasmashell (5.17.5) Qt Version: 5.14.0 Frameworks Version: 5.66.0 Operating System: Linux 5.4.15-arch1-1 x86_64 Distribution: Arch Linux -- Information about the crash: - What I was doing when the application crashed: Using VSCode, dragged a tab over to my desktop and created a sticky note. Clicked on VSCode again and desktop went black, but I could still see and interact with VSCode. - Unusual behavior I noticed: The crash does not seem to be reproducible. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7fb6d35bccc0 (LWP 545))] Thread 18 (Thread 0x7fb66a1a6700 (LWP 81874)): #0 0x7fb6d708bc45 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fb6d7c4bcc4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x7fb6d7c4bda2 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #3 0x7fb6d99b918b in () at /usr/lib/libQt5Quick.so.5 #4 0x7fb6d99b941b in () at /usr/lib/libQt5Quick.so.5 #5 0x7fb6d7c45fd6 in () at /usr/lib/libQt5Core.so.5 #6 0x7fb6d70854cf in start_thread () at /usr/lib/libpthread.so.0 #7 0x7fb6d78c82d3 in clone () at /usr/lib/libc.so.6 Thread 17 (Thread 0x7fb66b7fe700 (LWP 73331)): #0 0x7fb6d708bc45 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fb6d7c4bcc4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x7fb6d7c4bda2 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #3 0x7fb6d99b918b in () at /usr/lib/libQt5Quick.so.5 #4 0x7fb6d99b941b in () at /usr/lib/libQt5Quick.so.5 #5 0x7fb6d7c45fd6 in () at /usr/lib/libQt5Core.so.5 #6 0x7fb6d70854cf in start_thread () at /usr/lib/libpthread.so.0 #7 0x7fb6d78c82d3 in clone () at /usr/lib/libc.so.6 Thread 16 (Thread 0x7fb66bfff700 (LWP 67874)): #0 0x7fb6d708bc45 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fb6d7c4bcc4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x7fb6d7c4bda2 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #3 0x7fb6d99b918b in () at /usr/lib/libQt5Quick.so.5 #4 0x7fb6d99b941b in () at /usr/lib/libQt5Quick.so.5 #5 0x7fb6d7c45fd6 in () at /usr/lib/libQt5Core.so.5 #6 0x7fb6d70854cf in start_thread () at /usr/lib/libpthread.so.0 #7 0x7fb6d78c82d3 in clone () at /usr/lib/libc.so.6 Thread 15 (Thread 0x7fb69ca6b700 (LWP 67873)): #0 0x7fb6d78bd9ef in poll () at /usr/lib/libc.so.6 #1 0x7fb6b069cc14 in () at /usr/lib/libpulse.so.0 #2 0x7fb6b06aa059 in pa_mainloop_poll () at /usr/lib/libpulse.so.0 #3 0x7fb6b06b4301 in pa_mainloop_iterate () at /usr/lib/libpulse.so.0 #4 0x7fb6b06b43b1 in pa_mainloop_run () at /usr/lib/libpulse.so.0 #5 0x7fb6b06a461e in () at /usr/lib/libpulse.so.0 #6 0x7fb6b0622d1c in () at /usr/lib/pulseaudio/libpulsecommon-13.0.so #7 0x7fb6d70854cf in start_thread () at /usr/lib/libpthread.so.0 #8 0x7fb6d78c82d3 in clone () at /usr/lib/libc.so.6 Thread 14 (Thread 0x7fb69e298700 (LWP 65327)): #0 0x7fb6d708bc45 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fb6d7c4bcc4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x7fb6d7c4bda2 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #3 0x7fb6d99b918b in () at /usr/lib/libQt5Quick.so.5 #4 0x7fb6d99b941b in () at /usr/lib/libQt5Quick.so.5 #5 0x7fb6d7c45fd6 in () at /usr/lib/libQt5Core.so.5 #6 0x7fb6d70854cf in start_thread () at /usr/lib/libpthread.so.0 #7 0x7fb6d78c82d3 in clone () at /usr/lib/libc.so.6 Thread 13 (Thread 0x7fb69d9e9700 (LWP 62501)): #0 0x7fb6d708bc45 in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fb6d7c4bcc4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/libQt5Core.so.5 #2 0x7fb6d7c4bda2 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #3 0x7fb6d99b918b in () at /usr/lib/libQt5Quick.so.5 #4 0x7fb6d99b941b in () at /usr/lib/libQt5Quick.so.5 #5 0x7fb6d7c45fd6 in () at /usr/lib/libQt5Core.so.5 #6
[gwenview] [Bug 385496] New: There are two actions that want to use the same shortcut when using gwenview to open jpg and image files.
https://bugs.kde.org/show_bug.cgi?id=385496 Bug ID: 385496 Summary: There are two actions that want to use the same shortcut when using gwenview to open jpg and image files. Product: gwenview Version: Other (add details in bug description) Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: needs_verification Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: st.brad.tholo...@protonmail.com Target Milestone: --- When opening an image with gwenview the following dialogue appears: "There are two actions (Cut, Delete) that want to use the same shortcut (Shift+Del). This is most probably a bug. Please report it in bugs.kde.org" Click 'ok' and the image appears, checkboxed the option 'do not show this message again' prior to. gwenview version 16.04.3 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382435] Incorrect English in message
https://bugs.kde.org/show_bug.cgi?id=382435 Blake McBride <blake1...@gmail.com> changed: What|Removed |Added CC||blake1...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382435] New: Incorrect English in message
https://bugs.kde.org/show_bug.cgi?id=382435 Bug ID: 382435 Summary: Incorrect English in message Product: valgrind Version: 3.11.0 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: blake1...@gmail.com Target Milestone: --- The message is logically wrong. "All heap blocks were freed -- no leaks are possible" should be: "All heap blocks were freed -- no leaks were detected" -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 364161] New: Crash after duel monitor unlock.
https://bugs.kde.org/show_bug.cgi?id=364161 Bug ID: 364161 Summary: Crash after duel monitor unlock. Product: systemsettings Version: unspecified Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: scuba.bl...@gmail.com Application: systemsettings (4.11.20) KDE Platform Version: 4.14.9 Qt Version: 4.8.6 Operating System: Linux 3.16.7-21-desktop x86_64 Distribution: "openSUSE 13.2 (Harlequin) (x86_64)" -- Information about the crash: - What I was doing when the application crashed: Return from System lock, system set to lock after 5 minutes, password required. - Unusual behavior I noticed: Only primary monitor displaying. Used system settings to turn second monitor back on after manual restart of monitor via power button. - Custom settings of the application: Duel monitors. The crash can be reproduced sometimes. -- Backtrace: Application: System Settings (systemsettings), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7ff1a3d80800 (LWP 671))] Thread 2 (Thread 0x7ff185d5a700 (LWP 673)): #0 0x7ff199fc503f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7ff19e5f68cb in () at /usr/lib64/libQtScript.so.4 #2 0x7ff19e5f6909 in () at /usr/lib64/libQtScript.so.4 #3 0x7ff199fc10a4 in start_thread () at /lib64/libpthread.so.0 #4 0x7ff1a0d5400d in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7ff1a3d80800 (LWP 671)): [KCrash Handler] #5 0x7ff185d65c14 in KScreen::Output::id() const () at /usr/lib64/libkscreen.so.1 #6 0x7ff104787464 in () at /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so #7 0x7ff185d65319 in KScreen::ConfigMonitor::Private::updateConfigs() () at /usr/lib64/libkscreen.so.1 #8 0x7ff185d6534d in KScreen::ConfigMonitor::notifyUpdate() () at /usr/lib64/libkscreen.so.1 #9 0x7ff104784822 in () at /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so #10 0x7ff1a14b61fa in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4 #11 0x7ff104785f17 in () at /usr/lib64/kde4/plugins/kscreen/KSC_XRandR.so #12 0x7ff1a2e6c038 in () at /usr/lib64/libkdeui.so.5 #13 0x7ff1a14941ce in QAbstractEventDispatcher::filterEvent(void*) () at /usr/lib64/libQtCore.so.4 #14 0x7ff1a21ca4f0 in () at /usr/lib64/libQtGui.so.4 #15 0x7ff199cf6a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #16 0x7ff199cf6c48 in () at /usr/lib64/libglib-2.0.so.0 #17 0x7ff199cf6cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #18 0x7ff1a14cf0be in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #19 0x7ff1a21ca676 in () at /usr/lib64/libQtGui.so.4 #20 0x7ff1a14a0e6f in QEventLoop::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #21 0x7ff1a14a1165 in QEventLoop::exec(QFlags) () at /usr/lib64/libQtCore.so.4 #22 0x7ff1a14a65b9 in QCoreApplication::exec() () at /usr/lib64/libQtCore.so.4 #23 0x0040b4bb in () #24 0x7ff1a0c90b05 in __libc_start_main () at /lib64/libc.so.6 #25 0x0040b50c in _start () Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
