[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #37 from Kai Krakow --- The primary problem here seems to be grouping is based on the ClassClass string, not the ClassName string (which would be preferred for Chrome apps). I think this worked properly with Plasma 5.8.0 but now I'm on Plasma 5.8.2 and it's back to the old behavior. I compared Github but cannot see any changes in the code which would explain this (I checked plasma-desktop and plasma-workspace) so I guess the change is somewhere else (something I updated along Plasma). I'd like to patch this myself to get my preferred behavior back. Do you know where to look (maybe the exact commit) which changed this back to grouping by ClassClass instead of ClassName? When I had Plasma 5.8.0 installed, each Chrome app had its own instance on the taskbar (with child windows properly grouped within the correct task icon) even with the correct icon (not the general Chrome icon). All other apps worked correctly wrt grouping. So I think "wontfix" is not a satisfactory resolve status of this bug. Even unity gets this correct. I'm not even sure if the problem was properly understood when looking at the last comments. If working with a lot of Chrome apps, the behavior as it is right now is a real pita. OTOH, I don't want to disable grouping of Chrome altogether as the taskbar gets much too cluttered then. Comment #9 explained well what the difference is. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #39 from Kai Krakow --- So maybe this should be reopened? Although some of the discussion points into the wrong direction by saying that explicitly ungrouping applications is the same - but that is not true... So alternatively open a new bug report? I'm not sure... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #42 from Kai Krakow --- (In reply to Kai Uwe Broulik from comment #41) > Yup, Chrome broke it and I updated the mapping rules, will work again in > Plasma 5.8.4 [1]. There was also a logic flaw in the code that I fixed [2]. > > [1] > https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5. > 8&id=7c443aa53900521deab4fcd4641ea5273afc294e I already added this to /etc/xdg/taskmanagerrulesrc (it's the only file by that name on my system, so I'd expect it's the correct location). I restarted the machine to be sure it takes effect. But nothing changed: Chrome is still grouped no matter if I start it as web browser or as app container. The browser shows this in xprop: WM_WINDOW_ROLE(STRING) = "browser" WM_CLASS(STRING) = "google-chrome", "Google-chrome" One of the app windows (started from a .desktop entry created by chrome): WM_WINDOW_ROLE(STRING) = "pop-up" WM_CLASS(STRING) = "crx_ghaboaaodcboidcanphmnidfikjb", "Google-chrome" Desktop entry: $ ~/.local/share/applications $ cat chrome-ghaboaaodcboidcanphmnidfikjb-Default.desktop #!/usr/bin/env xdg-open [Desktop Entry] Version=1.0 Terminal=false Type=Application Name=Autotask Exec=/opt/google/chrome/google-chrome --profile-directory=Default --app-id=ghaboaaodcboidcanphmnidfikjb Icon=chrome-ghaboaaodcboidcanphmnidfikjb-Default StartupWMClass=crx_ghaboaaodcboidcanphmnidfikjb I expect both windows having distinct icons on the taskbar. > [2] > https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5. > 8&id=61860066a4cea845598fa4904607db1bba411356 Is this needed to fix the behavior? I could include it as Gentoo user patch and recompile... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 315488] icon-only task manager groups chrome/chromium web apps with chrome/chromium
https://bugs.kde.org/show_bug.cgi?id=315488 --- Comment #44 from Kai Krakow --- Okay, works... Gentoo backported some patches to 5.8.3 which didn't compile, I reverted back to the previous patch level with this patch included and now it works. What I am missing is correct icons. That seemed to work previously. But I guess it is now working correctly because now it matches the icon from the KDE launcher. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 348812] Crash in __strstr_sse2 after QSGRenderContext::initialize(QOpenGLContext*)
https://bugs.kde.org/show_bug.cgi?id=348812 Kai Krakow changed: What|Removed |Added CC|k...@kaishome.de | -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #6 from Kai Krakow --- Okay, so I'm now on Plasma 5.25 and this original issue seems fixed. But now, when I turn the monitor back on, the background image of that monitor is gone and completely black. I also cannot right click on the background: no context menu would appear. The panels are still there, and switching the panels to editing mode doesn't show the additional button bar to change background images, global design etc on that monitor (but it's shown on the others). Only restarting plasmashell will bring back the background image and context menu function. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #27 from Kai Krakow --- We probably need a system which stores a containment layout per number of monitors connecting. If an additional monitor gets connected, clone the next "lower count" layout. Then, sort the primary monitor to the beginning. That means, it would have a mapping `monitor counts -> layout` and then just counts the connectors in a predictive order instead of tracking EDIDs or connector names. At least for my use case, I don't care which monitor is connected to which connector, as long as my primary monitor is tracked correctly and all additional monitors are ordered after it. Predictive order could mean: primary first, then order by EDID, model or connector name. But I think there is at least one underlying severe problem here, and it seems to be a race condition: Plasma-shell, kscreen, the desktop background, and nvidia-settings do not seem to always agree about the order of screens. So sometimes, after a screen gets disconnected and reconnected, plasma-shell may end up with panels and backgrounds not matching my previous setup, or it ends up with no background at all (essentially making it impossible to right click) but the panels are still on that monitor. The components need to be synced somehow, it looks like each one gets its own view of the situation while Xorg still messes around with the detection. The setup should be transactional and only the new layout only reflected to the components if the detection phase is complete. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 --- Comment #409 from Kai Krakow --- (In reply to Nate Graham from comment #408) > This bug report is only about Plasma panels moving, not windows. That's a > different issue. Except it may be not... I'm seeing a similar behavior: Usually, windows store their last screen, and when reopened, restore to the same screen. But sometimes after reboot, this seems to be swapped (probably for the same reason panels moved to a different screen), and sometimes windows do not remember their position at all and go to some awkward default state (like horizontally maximized but not vertically) which is probably the same as when a panel "appears" on a disabled screen or not at all (the windows "remembered" screen does not exist in the screen real estate and just spawn at awkward positions, like partially maximized or halfway out of the screen). I just didn't mention it because I think it will be fixed for me when the panels become fixed. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412005] Konsole crashes when trying to paste (long texts) from clipboard
https://bugs.kde.org/show_bug.cgi?id=412005 Kai Krakow changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #2 from Kai Krakow --- (In reply to Justin Zobel from comment #1) > If you can reproduce the issue, please change the status to "CONFIRMED" when > replying. Thank you! I cannot reproduce that any longer. Pasting long text may be a bit laggy but it generally doesn't crash any longer. Closing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #33 from Kai Krakow --- (In reply to Iyán Méndez Veiga from comment #32) > Plasma 5.25.90 has a new issue and it's really unstable and difficult to > replicate. Every morning when I connect the laptop to the docking station I > have no idea what's going to happen. I can have both screen in duplicate > mode, I can have laptop screen on, and external without background, both > with wrong folder view instead of desktop mode, etc., etc. This behavior is > totally new and was introduced in this Beta. I tried to summarize this in > Bug 459368, but I mentioned it here not to loose the big picture. The seemingly random nature of this (as I understand your description) suggests that there is at least one other underlying bug that completely messes up replication of the problem. I'm seeing quite random behaviour with 5.25, and it looks like the different components of KDE/Plasma don't agree on the same state, which probably means there's also some racing between different components. I already suggested that in a previous comment. It's less likely to observe with just two monitors, but with three or more monitors it really gets messy, with different things (backgrounds, panels, folder views) each individually ending up on completely different monitors than what was configured. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #37 from Kai Krakow --- (In reply to Nate Graham from comment #35) > Unfortunately this is exactly right. [...] > The current system needs to be thrown away and replaced with > something better-engineered from the start, which is in progress for Plasma > 5.27. Thanks for confirming, Nate, very much appreciated. To me this means I'll stay silent for that time to not add unnecessary noise, accepting all strange behavior and trying to live with it. I hope this gets back-ported to 5.26 as 5.27 will probably not arrive before summer 2023. My faith is not lost yet. :-) -- You are receiving this mail because: You are watching all bug changes.
[krdc] [Bug 377911] [Wayland] RDP doesn't work under Wayland
https://bugs.kde.org/show_bug.cgi?id=377911 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450301] On KWin 5.24 X11 Nvidia, when reenabling compositing, windows begin flickering and flipping upside-down
https://bugs.kde.org/show_bug.cgi?id=450301 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #12 from Kai Krakow --- I can confirm this. A mostly reliable reproducer is starting a Steam Proton game which has a launcher that detect DirectX capabilities, e.g. the Elite Dangerous Launcher. Such launchers generate a full screen window for an blink of an eye which disables the compositor and automatically enables it again (I'm forcing composition off through a kwin rule which looks for client windows named "(gamescope|steam_app_)", otherwise games stutter unpredictably in my dual monitor setup and both my monitors drift apart with vsync over time (and X11 always syncs all monitors in a single loop thus syncing to the slowest monitor). This tight disable/enable loop seems to be enough to initially trigger the bug but it usually only occurs when the game ends and closes it's final window (tho, not exclusively, it still may trigger the bug when the launcher starts). The game itself is unaffected. Using shift+alt+F12 to disable compositing cures the flipped and flickering desktop but only until I re-enable compositing. Only restart kwin_x11 fixes it. After it happened once, it is very likely to be triggered more easily, a full reboot is needed to get rid of the behavior for a while. Games that do not trigger tight enable/disable intervals for compositing seem to be less likely trigger the bug. "Force full composition pipeline" is enabled to fix tearing in multimonitor setups. It may be part of the problem, I was never seeing that on my single monitor setup (but this is at least 2 years ago). -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 469279] New: Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 Bug ID: 469279 Summary: Running akonadi servers easily doubles or triples VRAM usage Classification: Frameworks and Libraries Product: Akonadi Version: 5.23.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: k...@kaishome.de CC: c...@carlschwan.eu Target Milestone: --- SUMMARY After a long time, I wanted to give Akonadi a new chance and installed it. After some time I noticed much worse gaming performance related to VRAM pressure. I've monitored nvidia-smi to see that my idle desktop now uses 3.8 GB of VRAM, with a lot of akonadi resource processes allocating 4 MB each from the driver directly but also the Xorg process was ballooned up to 2.7 GB of VRAM usage even after a fresh reboot. Usually, after reboot, Xorg would use around 800 MB of VRAM with some background processes having 4 MB allocated each, result in around 1.2 GB of VRAM usage for a freshly booted desktop, and up to 2.5 GB after some time of use (that's still a lot but a different concern). STEPS TO REPRODUCE 1. Install akonadi 2. Reboot 3. Observe nvidia-smi output after fresh boot and after some time of use OBSERVED RESULT Over 3 GB of VRAM usage after a fresh boot, increasing to almost 5 GB after some time of use. EXPECTED RESULT Stay below 2.5 GB of VRAM with some web browser windows open and Steam running. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS # equery l nvidia-drivers * Searching for nvidia-drivers ... [IP-] [ ] x11-drivers/nvidia-drivers-525.116.03:0/525 ADDITIONAL INFORMATION Dual-monitor setup with "force full composition pipeline" enabled in nvidia-settings. nvidia-smi without akonadi running: Tue May 2 19:33:30 2023 +-+ | NVIDIA-SMI 525.116.03 Driver Version: 525.116.03 CUDA Version: 12.0 | |---+--+--+ | GPU NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===+==+==| | 0 NVIDIA GeForce ... Off | :01:00.0 On | N/A | | 0% 48CP546W / 370W | 2494MiB / 12288MiB | 30% Default | | | | N/A | +---+--+--+ +-+ | Processes: | | GPU GI CIPID Type Process name GPU Memory | |ID ID Usage | |=| |0 N/A N/A 1625 G /usr/libexec/Xorg1734MiB | |0 N/A N/A 2328 G /usr/bin/kwin_x11 149MiB | |0 N/A N/A 2329 G /usr/bin/ksmserver 4MiB | |0 N/A N/A 2331 G /usr/bin/kded5 4MiB | |0 N/A N/A 2509 G /usr/bin/plasmashell 180MiB | |0 N/A N/A 2570 G ...de-authentication-agent-14MiB | |0 N/A N/A 2573 G ...ec/xdg-desktop-portal-kde4MiB | |0 N/A N/A 2680 G /usr/bin/python3.10 4MiB | |0 N/A N/A 2684 G ...lib64/libexec/kdeconnectd4MiB | |0 N/A N/A 2685 G /usr/bin/kleopatra 4MiB | |0 N/A N/A 2686 G /usr/bin/keepassxc 4MiB | |0 N/A N/A 2698 G /usr/bin/kaccess4MiB | |0 N/A N/A 2702 G .../libexec/DiscoverNotifier4MiB | |0 N/A N/A 3942 G ...aw,WebRTCPipeWireCapturer 88MiB | |0 N/A N/A 3945 G /usr/bin/kwalletd5 4MiB | |0 N/A N/A 4159 G ...b64/libexec/kf5/klauncher4MiB | |0 N/A N/A 4301 G ...-browser-integration-host4MiB | |0 N/A N/A 6838 G ...veSuggestionsOnlyOnDemand 10
[Akonadi] [Bug 469279] Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 --- Comment #1 from Kai Krakow --- BTW: Running "kcmshell5 qtquicksettings" and forcing software rendering for plasma completely eliminates the issue (with Xorg staying really low on VRAM) but then plasma loudly complains about non-optimal rendering settings and I fear this can even reduce game performance if an application renders in parallel to a game (as can be observed when forcing software rendering for Discord which completely degrades GPU performance while gaming). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 469281] New: windows with background blur (e.g., konsole) flicker and leave mouse trails
https://bugs.kde.org/show_bug.cgi?id=469281 Bug ID: 469281 Summary: windows with background blur (e.g., konsole) flicker and leave mouse trails Classification: Plasma Product: kwin Version: 5.27.4 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@kaishome.de Target Milestone: --- SUMMARY When using kwin_wayland, windows which use transparency with background blur flicker during screen updates and the mouse point may leave square blocks of trails in the background color (as if no background blur was used). This can be observed both with NVIDIA and Intel. Disabling background blur in konsole fixes the issue but other windows may (and even the plasma panels) may still be affected, tho the problem is most prominent with konsole. STEPS TO REPRODUCE 1. Enable background transparency/blur in konsole 2. Update screen contents in konsole and move the mouse point around within the window 3. Move the window around OBSERVED RESULT Trails of background-colored blocks are left behind the mouse cursor, konsole window contents may flicker heavily. EXPECTED RESULT No flickering, no mouse trails. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS ADDITIONAL INFORMATION Also happens with Intel (Gen3 iGPU): Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz But usually, flickering cannot be observed with latest Plasma version but mouse trails are still present. The flicker problem mostly went away after I bumped the iGPU shared memory area from 32 to 512 MB (and it also fixed the lockscreen freezing until I "loginctl unlock-session" from alt+F2 and restart kwin which is not feasible with wayland). I disabled konsole background blur on that iGPU for now because it really hurts desktop rendering performance, so it less a problem on that iGPU anyways for me which mostly lefts us with the issue on NVIDIA. -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 145911] display irc style /me
https://bugs.kde.org/show_bug.cgi?id=145911 Kai Krakow changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |UNMAINTAINED --- Comment #5 from Kai Krakow --- Closing as obsolete/abandoned -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #12 from Kai Krakow --- I partially found automounts triggering the problem. With automounts enabled, right clicking on dolphin window icons or starting konsole (probably every app that is somehow involved in checking mount point stats) can stall either plasma (when a context menu is displayed) or stall konsole startup for multiple seconds up to a minute. Interestingly, just using "cd" to switch to a directory with automount point and running "ls" almost instantly returns and shows the directory. This affects both NFS and local automounts for me but also remote filesystems mounted via kio (and the latter seem to contribute a lot more to the stalls). Once NFS automounts are mounted, the system does no longer stall konsole, kio is eventually cached by then but the dolphin window icon context menu is still affected and blocks plasma while stalled. On a second system which is configured almost identically, the same behavior cannot be observed or it is much less pronounced. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] New: cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Bug ID: 469283 Summary: cannot copy files to smb when accessing a DFS share Classification: Frameworks and Libraries Product: kio-extras Version: 23.04.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Samba Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de CC: sit...@kde.org Target Milestone: --- SUMMARY When accessing a Windows DFS share through kio, dolphin complains about not enough space in the destination copying data to the share. Running "df" on the kio mount confirms that there are 0 bytes reported free, and the reported file system size is also 0 bytes. From cmdline, files can still be created or copied. Accessing the same share directly from the DFS member reports correct sizes and allows dolphin to copy files to the share. Mounting DFS directly via CIFS kernel support reports the correct values. SMB shares: \\domain.local\DFS\Storage -> 0 bytes free and 0 bytes size \\member1.domain.local\Storage -> sizes reported correctly \\member2.domain.local\Storage -> also reported correctly STEPS TO REPRODUCE 1. Setup a DFS share with two member servers and DFSR sync 2. Access share via DFS share via kio to check for free space 3. Access share directly on member server via kio to check for free space OBSERVED RESULT kio-smb reports 0 bytes free and 0 bytes file system size, preventing kio clients from writing data due to out of space condition (actually, it may complain about insufficient permissions sometimes but that's not true, it's still "out of space"). EXPECTED RESULT kio-smb should report file system stats correctly for DFS shares. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux 2.13 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.1.26-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080 Ti/PCIe/SSE2 Manufacturer: ASRock Product Name: Z690 Pro RS -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #2 from Kai Krakow --- (In reply to Harald Sitter from comment #1) > Please provide reproducible steps for 1. Setup a DFS share with two member > servers and DFSR sync On two Windows Server hosts, install DFS replication services. Install DFS namespace services on at least one host and setup a DFS namespace using the first two hosts as target servers. Then create a replication group between those two members to keep the shares in sync. I'm not sure if DFS replication is actually necessary to show the 0-space-bug, it may be sufficient to use a single DFS target without replication, and just point kio-smb to access the share through the DFS namespace, although using DFS with a single target share is not really that useful. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb when accessing a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #4 from Kai Krakow --- (In reply to Harald Sitter from comment #3) > Not exactly the level of detail I wanted but it'll do :) > > And you are quite certain this is with kio-extras 23.04? This is a good point... There are two systems, one is more "bleeding edge" and uses the DFS share via VPN link, so I should retest it with 23.04 (because it was recently updated and I didn't retest there since then): # equery b /usr/lib64/qt5/plugins/kf5/kio/smb.so * Searching for /usr/lib64/qt5/plugins/kf5/kio/smb.so ... kde-apps/kio-extras-23.04.0 (/usr/lib64/qt5/plugins/kf5/kio/smb.so) The other system (directly connected to the server LAN segment) has: # equery b /usr/lib64/qt5/plugins/kf5/kio/smb.so * Searching for /usr/lib64/qt5/plugins/kf5/kio/smb.so ... kde-apps/kio-extras-22.12.3 (/usr/lib64/qt5/plugins/kf5/kio/smb.so) That system shows this problem as recently as a few days ago. Do you mean to say that this may have been fixed in 23.04? -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Summary|cannot copy files to smb|cannot copy files to smb if |when accessing a DFS share |accessing as a DFS share -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #6 from Kai Krakow --- OTOH, this may also be fixed in Dolphin rather than kio (if there's no way around that behavior): If Dolphin detects 0 bytes free and 0 bytes size at the same time, it should infer that there's no information about free space and just try writing the file. I'm pretty sure it's not kio preventing the write due to this condition (because when launching the terminal from Dolphin, it will put me into a kio mounted directory and I can create files there just fine). -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 --- Comment #7 from Kai Krakow --- (In reply to Harald Sitter from comment #5) > > Do you mean to say that this may have been fixed in 23.04? > > Yes > https://invent.kde.org/network/kio-extras/-/commit/ > 46d3f2fd41dece1d49e7295ae986d8e3960e78fb Oh wow... Thanks, I'll try. I add this to the patch queue of emerge and reinstall the package. I'm guessing it will apply to 22.12.3 without conflicts. I'll close this if it works for me. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 469283] cannot copy files to smb if accessing as a DFS share
https://bugs.kde.org/show_bug.cgi?id=469283 Kai Krakow changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Kai Krakow --- Thanks, it is fixed by your commit. Sorry for not taking more attention to my other system which recently updated to 23.04 - I wasn't really aware of that fact when I wrote the bug report. *** This bug has been marked as a duplicate of bug 431050 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 431050] SMB error: "There is not enough space on the disk to write smb://..."
https://bugs.kde.org/show_bug.cgi?id=431050 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #24 from Kai Krakow --- *** Bug 469283 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 469279] Running akonadi servers easily doubles or triples VRAM usage
https://bugs.kde.org/show_bug.cgi?id=469279 --- Comment #3 from Kai Krakow --- Thanks for investigating. I think this example shows that KDE/Plasma should treat VRAM as a valuable resource, and it affects a lot of other KDE background processes, too. So maybe creating some infrastructure to have one single process display dialogues for background processes may be the way forward. But I understand that this is a big change. As a less intrusive interims solution, Akonadi agent and resource processes could be forced to use Qt software rendering only. It probably won't hurt too much because most of these processes only open simple dialogues, and usually probably only in the event of errors or warnings, not as part of working normally. I found that forcing Qt software rendering for the full desktop to eliminate VRAM ballooning but, as already mentioned, I'm not sure how badly it will affect desktop performance, especially if desktops apps need to render in parallel to a game. Also, it somehow prevents window previews on the taskbar to work so it has a visible impact on user experience. But it may be acceptable for Akonadi dialogues for the time until this is fixed. I found no way to force software rendering only for processes launched by Akonadi, it should be as easy as injecting an environment variable into the launcher but I don't know how or where to do that. There's `/usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service` but I'm not sure if this is the right place for trying to inject environment variables, or if that is the launcher of the main process at all... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 187172] truncated configuration files on power loss or hard crash
https://bugs.kde.org/show_bug.cgi?id=187172 --- Comment #47 from Kai Krakow --- (In reply to Martin Steigerwald from comment #46) > Nowadays where Ext3 should not be in wide use anymore, if at all, and > nowadays where many people use flash based storage, I am strongly for just > making sure to sync where needed. > > That written, I did not see any truncated config file since ages. I still > have "KDE_EXTRA_FSYNC=1" set, but whether this actually really makes a > difference, given some of the comments above, I do not know. Anyway, I'd > just sync by default. It really can't be a performance issue anymore – > except maybe on embedded device with some slow SD card –, especially as > unchanged files are not rewritten anymore. If I remember correctly, you may be using btrfs. On btrfs, this is actually not needed, it works fine without fsync and is actually faster that way no matter the storage technology. I'm running with `KDE_EXTRA_FSYNC=0` since years on btrfs and never had a problem. I suggest that the behavior is kept to optionally disable fsync/fdatasync, but it should befault to "on". The problem is with file systems which do not commit metadata and data properly in a single transaction or in expected order, e.g. xfs does this and writes data lazily or delayed. In that case, xfs ensures that you do not see stale or old data after a crash by zeroing or truncating the affected files. I think ext3/ext4 does something similar unless you use its full journal mode (which is a lot slower, ofc), where xfs probably behaves like ext4 with "journal=writeback". Especially with btrfs, the argument is not whether it's on flash or spinning disks: fsync/fdatasync can significantly slow the system down because btrfs may have a rather long list of outstanding transactions it would have to write then (blocking) until reaching the transaction affected by the sync. This can take a long time and blocks the system even on flash disks. So if this discussion is about whether we should remove `KDE_EXTRA_FSYNC`, I'd rather not have it force-enabled, especially because KDE seems to be very busy with its config files and reads and writes them a lot (similar to the cache directory). IMHO, the variable could be changed to require `KDE_DISABLE_EXTRA_FSYNC=this_is_dangerous_and_I_know_what_I_am_doing`. This may make it more obvious to people who blindly follow some internet guides to "make things faster" that they may be doing something harmful. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484323] High CPU load of kwin_x11 when locking or turning off the screen
https://bugs.kde.org/show_bug.cgi?id=484323 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #36 from Kai Krakow --- I can confirm this for 6.1.1. I'm using 4 monitors, one of them is sometimes turned off. Perf data looks like this: # Overhead Command Shared ObjectSymbol # ... ... ... # 24.22% kwin_x11 [vdso] [.] __vdso_clock_gettime 15.66% kwin_x11 libc.so.6[.] __sched_yield 10.43% kwin_x11 [unknown][k] 0x81c00150 1.71% kwin_x11 libc.so.6[.] clock_gettime@@GLIBC_2.17 1.46% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d13 1.24% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d00 1.02% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea66 0.78% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea61 0.72% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00a03904 0.71% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00b00d30 0.68% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x009eea59 It looks like most of the time is spent in a tight loop getting the clock and yielding. Most of the time is spent outside of kwin_x11 but filtering by dso shows where it is involved: # dso: kwin_x11 # # Total Lost Samples: 0 # # Samples: 5K of event 'cpu_atom/cycles/Pu' # Event count (approx.): 2421254389 # # Overhead Command Symbol # ... ... # 0.12% kwin_x11 [.] KWin::BlendChanges::isActive 0.07% kwin_x11 [.] QtPrivate::QCallableObject, void>::impl 0.04% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.03% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.03% kwin_x11 [.] KWin::ApplicationX11::metaObject 0.03% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.03% kwin_x11 [.] KWin::ContrastEffect::doContrast 0.02% kwin_x11 [.] KWin::ZoomEffect::slotWindowDamaged 0.02% kwin_x11 [.] KWin::GlxLayer::doBeginFrame 0.02% kwin_x11 [.] KWin::PaintData::yTranslation@plt 0.02% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.02% kwin_x11 [.] KWin::EffectsHandler::prePaintScreen@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::isActive 0.02% kwin_x11 [.] KWin::EffectWindow::isDesktop@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::drawWindow 0.02% kwin_x11 [.] KWin::GlxBackend::primaryLayer 0.02% kwin_x11 [.] KWin::SlideEffect::isActive 0.02% kwin_x11 [.] QRegion::end@plt 0.02% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.02% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.01% vsync event mon [.] operator delete@plt 0.01% kwin_x11 [.] KWin::GlxBackend::makeCurrent 0.01% vsync event mon [.] QMetaObject::activate@plt 0.00% vsync event mon [.] QtPrivate::QCallableObject, void>::impl # Samples: 1M of event 'cpu_core/cycles/Pu' # Event count (approx.): 737751025988 # # Overhead Command Symbol # ... . . # 0.01% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintWindow 0.00% kwin_x11 [.] QRegion::~QRegion@plt 0.00% kwin_x11 [.] KWin::BlurEffect::blur 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::GlxBackend::doBeginFrame 0.00% kwin_x11 [.] KWin::GlxContext::makeCurrent 0.00% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.00% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #44 from Kai Krakow --- (In reply to tagwerk19 from comment #43) > I think the dust has probably settled here after: > https://invent.kde.org/frameworks/baloo/-/merge_requests/131 > and cherrypicked for KF5 > https://invent.kde.org/frameworks/baloo/-/merge_requests/169 These work fine for me, I'm actually using baloo again in production. > There's also been > https://invent.kde.org/frameworks/baloo/-/merge_requests/121 Actually, `MemoryHigh=512M` is quite aggressive. It can lead to swap storms and cache thrashing of baloo under memory pressure because the process itself is already 512M big, this leaves no space for caching which is important for baloo to work with proper performance (consider that memory cgroups also account cache usage). Especially the sub process baloo_file is hurt by this a lot while indexing new files. I personally used `MemoryHigh=2G` to fix this for my system - but this parameter really depends a lot on the system environment. The service shows a peak usage of 1.3G with almost no swap usage (less than 30M), so `MemoryHigh=1536M` may be fine. > and > https://invent.kde.org/frameworks/baloo/-/merge_requests/148 No objections, it makes sense. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #46 from Kai Krakow --- (In reply to tagwerk19 from comment #45) > Yes, there's been a handful of bug reports where I've "blamed" the 512M > limit. > > I tentatively recommend "MemoryHigh=25%". I don't suppose many people run on > systems with 2G RAM (even as VM's) and having a percentage means Baloo gets > a lot more room to breath on systems with 8G. > > I think "MemoryHigh=40%" is still quite reasonable and I would also include > a "MemorySwapMax=0" to forestall swapping (which does seem to cause problems) MemorySwapMax can lead to OOM situations, even for other processes, if the only swap victim would be baloo. It is fine to swap out some dead pages which the process never uses. And we should be careful with percentages: `MemoryHigh` sets a priority at which the kernel memory manager chooses processes to reduce memory usage (by discard caches, flushing writeback, or swapping anonymous memory). We actually want this to happen, we should be careful to not make baloo the last resort by accidentally giving it the highest memory priority. If we want to limit it, `MemoryMax` should be set (then baloo will never get more memory). But `MemoryHigh` should be set to a reasonable minimum we want to protect for the process so it can make forward progress. Setting it too high creates an inverse effect for other important processes of the desktop. It the lower bound of what is considered high memory usage before making memory available to other processes. Memory is taken away from processes with the highest `MemoryHigh` last. As an idea, baloo could watch `/proc/pressure/memory` and if latencies go high, it could pause for a while and flush its own caches. One cannot try to emulate such a behavior with `MemoryHigh`. Maybe the memory limits should be removed completely, and rather let the kernel do the job using mgLRU (which could be recommended for distributions if it works fine), and then let baloo watch memory pressure instead to throttle itself. The problem is not with baloo reading files and using CPU, it's already highly optimized here. The problem is with how the database uses memmap, so it's directly competing with important desktop processes needing resident memory (it's not designed to compete with other processes for memory). Using memory pressure, we could mark selected memory ranges as "not needed" and flush unwritten data early so it becomes available. I had no more problems with baloo until it added the `MemoryHigh=512M` parameter, so I added another one to force 2G instead. Which makes me wonder if we need that parameter at all. Just my 2 cents, no need to re-open. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #49 from Kai Krakow --- (In reply to tagwerk19 from comment #47) > That said, I've not noticed the percentages behaving differently than a > defined amount of memory (so, I think a "MemoryHigh=25%" on a 2GB system > acts the same as a "MemoryHigh=512M"). It would be interesting if this was > not the case... No, it should not be different. In the end, it boils down to fixed numbers as can be seen in `systemctl --user status kde-baloo.service`: # Memory: 136.4M (high: 2.0G available: 1.8G peak: 1.3G swap: 18.4M swap peak: 18.5M zswap: 6.9M) (where "high" is calculated from percentage to this number) > I'm pretty sure the "MemoryHigh" is a soft limit, I was able to push the > usage to just a little above the given limit but the process slowed down > (markedly, when I pushed hard), I think when trying to claim more memory. MemoryHigh is not a limit. MemoryHigh is an indicator/hint for the kernel beyond which value the process group is considered to use a high amount of memory. Now, if the kernel needs memory, it will reclaim memory from process groups first that are most above their "MemoryHigh" value. Thus, if you make this very high, the kernel will decide to reclaim memory from baloo last because it is potentially the only service with a very high "MemoryHigh" value. The service is allowed to go beyond that memory usage just fine as long as the kernel has no need for other memory. This is also a problem in itself if mixing non-memory constrained services with ones that have this setting. The system becomes very unbalanced unless you adjust it for your very own needs. Leaving `MemoryHigh` empty instructs cgroups to balance memory usage in a fair way. > I > tried the same with MemoryMax but this seemed to be a hard limit. Yes, it is a hard limit. Allocations beyond `MemoryMax` will force the process group to swap out inactive memory of itself. > I tried > setting a MemoryHigh with a slightly higher MemoryMax but it didn't seem to > bring any benefits, the MemoryHigh on its own seemed to be quite effective > at limiting Baloo's memory use. Cannot work. `MemoryHigh` is not a limit, it's a hint for the memory management when to consider a service to use "too much" memory, so services beyond that allocation will be considered for reclaim first. Or viewed from the other side: `MemoryHigh` is a type of resident memory protection which the kernel _tries_ to guarantee to the service (`MemoryMin` will force the guarantee). > I'm also pretty sure that even with a defined MemoryHigh, Baloo releases > memory when other processes require it. Yes, because it's a "soft guarantee", not a "soft limit". If the kernel has no more other processes to reclaim memory from, it will start reclaiming memory from `MemoryHigh` services below their setting, in order of priority that makes sense in that context. Baloo itself surely will free memory, too, by itself, and that's reflected here. Those memory allocations also include cache which baloo cannot directly control. The kernel tracks page cache ownership per cgroup, and accounts that to memory usage, too. I'm pretty sure `MemoryHigh` has been set so low (512M) because someone considered it a soft limit, but it's a soft guarantee. And setting it too low will hint the kernel to reclaim memory from such processes first - and that's usually cache before swapping memory out (depends on vm.swappiness). Thus, `MemoryHigh` should be set to a proper value that includes the active working set of memory pages for the process + a good value for cache to let it do it's job without stuttering the desktop. That settles around 1.5G of memory for me. But OTOH, that means, we will also protect its memory even if baloo is idle (and may be fine with using less than 1.5G RAM including caches). Thus I think, it may be a better idea to completely leave that value empty, maybe only include it as a comment with explanation so users can tune it easily with `systemctl --user edit kde-baloo.service`. > Certainly, there was dropping and rereading of clean pages when Baloo was > closing on the limit. That was visible in iotop. I noticed in "pathological > cases", indexing large quantities of data and having to manage very many > dirty pages, pushed Baloo to swap and performance very clearly suffered > (even when the rest of the system has sufficient space). I think it's > (likely) worthwhile adding the MemorySwapMax=0 for Baloo to stop it reaching > that point (although only if MemoryHigh is reasonable). The argument being > an OOM for Baloo is (likely) better than it swapping. This is a value > judgement through... `MemoryHigh` is a two-edged sword... You can stop the observed behavior by using a high valu
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #51 from Kai Krakow --- (In reply to tagwerk19 from comment #50) > (In reply to Kai Krakow from comment #49) > > Thank you for the insights. That's a lot more to think about... You're welcome. > What we had previously, of BTRFS presenting "another different" device > number on reboot and Baloo's initial scan for changes not committing at > intervals, that was a catastrophic combination. I initiated the idea to fold the uuid into the dev/inode feels somehow, I just hadn't time exploring the source code. Luckily, someone finally implemented that idea. \o/ > I think, in *general*, > nowadays Baloo does not demand so much memory. Maybe though I should check > when a lot of files have been deleted and Baloo has to catch up. How Baloo > might behave when it is squeezed for memory (rather than being the culprit), > that's something new to think about... Yeah exactly. I think one remaining issue is when system performance suffers not because baloo uses too much memory but because it becomes squeezed into too little memory. Thanks for testing it. I'm currently running fine with `MemoryLow=512M` and no high limit, seems to work great so far even with games running and while streaming, using btrfs on bcache with hdds. With that configuration, more baloo memory has been pushed into swap - but it was never reclaimed so its probably inactive memory anyways and should be in swap. I'd recommend to look into the "below" tool (an alternative implementation to "atop"), it tracks memory usage via cgroups and thus can tell you also the accounted cache memory of a process group where "htop" or "top" only show resident process memory without caches accounted. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] New: turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Bug ID: 453554 Summary: turning one monitor off kills the panel configuration of the second monitor Product: plasmashell Version: 5.24.5 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Multi-screen support Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de CC: aleix...@kde.org, notm...@gmail.com Target Milestone: 1.0 SUMMARY Monitor setup (xrandr dump at the end): Left main monitor: 4k displayport * top plasma panel with activity switcher, global menu, date and time, systray * bottom plasma panel with launch menu, icon window list, desktop switcher Right small monitor: full HD HDMI connected via DP * top plasma panel with window list, time, bluetooth applet, volume applet TV: 4k, HDMI * clone of left monitor (for couch gaming) Graphics: NVIDIA GTX 1660 Ti 6GB with Xorg Whenever I turn off my main monitor, all its panels move over to the right monitor. The same happens if the TV turns off or goes to sleep. Sometimes (probably before 5.24.5), I can see two overlapping panels at the top (my main top panel plus the simple side monitor panel) but since 5.24.5 the panel moves consistently, replacing the configuration of the right monitor. This was fine most of the time before 5.24.5 and consistently fine before 5.24.4: The panels were restored when I turned the main monitor back on, only messing up if plasma crashed or shut down before turning the monitor back on. But now it consistently throws away the plasma configuration of the right monitor: After turning the main monitor back on, I'm left with an empty default desktop on the right monitor, no custom background image, no panels, but all open windows moved to this monitor. Looking at the output of `qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.dumpCurrentLayoutJS` I can see that each incident adds another panel configuration in `layout.panels` but I have no way of getting it back. `plasmashellrc` has these lines: ``` [ScreenConnectors] 0=DP-4 1=HDMI-0 2=DP-1 ``` It also had `2=:0.0` followed by `3=DP-1` but I removed that out of desperation. It wasn't present in older backups of my system. It didn't change anything about the behavior, tho. STEPS TO REPRODUCE 1. Use a setup like I described above 2. Turn the displayport monitor off which seems to disconnect it from the system (my DP monitor and HDMI TV do that when turning them off, my HDMI monitor doesn't do it and seemingly stays connected/detected) 3. Observe the panels move over to the second screen 4. Turn first monitor back on OBSERVED RESULT After step 4, the panels move back to the monitor just turned back on but step 2/3 seem to have displaced the panel/desktop configuration of the second monitor, and after step 4, plasma will replace it with an empty default configuration. EXPECTED RESULT The panels should be properly restored to their respective original monitors. I guess it's fine and wanted that disconnecting the primary monitor would move panels over to remaining monitors, e.g. for laptop usage. But when I restore the original monitor connection for which I configured the panels, that configuration should be restored, or at least I should have an easy way to choose which panel configuration I want to restore. But in my case, it's gone for good although it still seems to live in the qdbus layout dump (and it's piling up there because I need to recreate the layout multiple times per day). I think Plasma should store and apply layouts like this: Store a layout of each monitor, also store a flag if this was made on the primary monitor. If the current monitor is the primary monitor, use the panel layout of the original primary monitor. Otherwise fall back to the layout originally defined for this monitor. Do not remove but swap layouts when the primary layout flag is involved. Move the primary layout flag only when the layout is actively edited. SOFTWARE/OS VERSIONS Operating System: Gentoo Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.15.37-gentoo (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 31.1 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2 ADDITIONAL INFORMATION This behavior was triggered very rarely before 5.24.4, easily triggered with 5.24.4, and consistently triggers with 5.24.5. Given that history of behavior, it's probably some race condition and is not intentional. My clone monitor layout may play a role in this because I found in older versions some months back, that sometimes plasma panels would be defined for my TV instead of my main monitor (when I disabled the TV, all panels were gone). I had situations when the panels actually moved to a "third" monitor right of my seco
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #3 from Kai Krakow --- (In reply to Marco Martin from comment #1) > are all outputs connected to the internal videocard or there are external DP > dongles involved? No dongles but there is one DP-to-HDMI cable. Not sure if that counts as a dongle. The iGPU card is not active, I'm only using the PCI-e card. > in plasmashell itself it doesn't seem that anything have happened between > 5.23 and 5.25, wonder in what part the breaking change was. This morning when I turned the monitors back on, all was fine. So it may be some timing issue or something is racing. Or it just created "enough" panels in the qbus javascript dump that it no longer creates new configurations but just chooses from the existing ones. I'll observe it for some time and report back. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #4 from Kai Krakow --- Also, Plasma version is probably not the only thing that changed. The nvidia driver was also updated at least once, and Xorg components were also updated at least once. But I cannot really pin-point that to one of those changes, Plasma version seems to be the strongest indicator. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #5 from Kai Krakow --- It worked for a few days in a row. But yesterday evening and today morning, this happened again and the behavior is quite random: This time, only the top panel moved to the wrong screen while the bottom panel stood in place. Or maybe it's rather the other way around: Turning my main monitor off probably moves the panels to the other monitor, and when turning it back on, the panels do not properly move back. The interesting part this time is that the bottom panel behaved properly while the top panel behaved wrong. Latest 5.24 doesn't fix anything. Let's see if 5.25 solves something. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Kai Krakow changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #8 from Kai Krakow --- (In reply to Nate Graham from comment #7) > Cool, thanks! Can you file a new bug report for the new issue? > > Out of curiosity, does the wallpaper show up after 10 seconds or so? Re-opened, because unfortunately, the bug is still there: With the new panel management tool (available from the edit mode), I can now clearly see how panels move to the wrong screen. This usually happens when connected monitors swap positions: The last few days, I'm pretty sure I had the following order in the "Drag panels and desktops around" dialog: DP-4, DP-1, HDMI-0 (deactivated). Today, when I turned my monitors on, the order changed to "DP-4, HDMI-0 (deactivated), DP-1", and the panels have moved to the deactivated screen (but not the background image, that moved to a different screen a few days before already). Please take note that the background image shows the same bug but moves independently of the panels, so there are probably race conditions. I've set different wallpapers to track this: Both the wallpapers and the panels move to different screens, and they do NOT move the same way: Sometimes only the wallpaper moves to a different screen, sometimes only one panel of a screen moves, sometimes two panels of the same screen move. At least the panel management tools allows me to simply move panels and wallpapers back to their correct screen. The system hasn't been rebooted. All I do is turning off the monitors, and one monitor completely disconnects from the graphics card when turned off. So to reproduce it, in the worst case you'll have to physically disconnect the monitor because many monitors keep their connector online when turned off - but one of my monitors doesn't. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 --- Comment #9 from Kai Krakow --- Created attachment 150180 --> https://bugs.kde.org/attachment.cgi?id=150180&action=edit configuration completely doesn't match the output Here's an example of messed up content: As you can see, the panels overlap on the right screen although two of them are supposed to be on the left screen. Also, the left screen shows the background image of the deactivated screen. Dragging the panels back and forth in the editor fixes the panel placement. But dragging the background image will simply leave a black background that is not clickable or interactable anymore until I restart the plasmashell service. So, no - it's not fixed. I'd even say it shows the exact same behavior in 5.25 as it did in 5.24. Configuration and outputs do not match, panels are in very different locations than what Plasma thinks they should be. Rarely, I see how all panels disappear when I turn a monitor back on, and then re-appear around 5-10s later if that is what you were asking for. This seems to have the effect that plasma doesn't become confused about the monitor layout. I've last seen that in 5.24 but not yet in 5.25. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453554] turning one monitor off kills the panel configuration of the second monitor
https://bugs.kde.org/show_bug.cgi?id=453554 Kai Krakow changed: What|Removed |Added Version Fixed In|5.25| -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356727] Panel sometimes disappears on hotplug/re-plug/sleep/wake
https://bugs.kde.org/show_bug.cgi?id=356727 --- Comment #76 from Kai Krakow --- (In reply to Nate Graham from comment #75) > As a result it would > probably be best if people who are still affected could file new bug > reports, and I will try my best to triage them accordingly. Thanks! I still have this open bug report which is similar but panels move to different screens (even disabled screens sometimes): https://bugs.kde.org/show_bug.cgi?id=453554 But the initial title doesn't exactly reflect the behavior under 5.25 because I can now recover the panels from the panel editor. Should I set a new title and set the new version number? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #4 from Kai Krakow --- (In reply to Nate Graham from comment #2) > In general, this is why KIO exists: to provide asynchronous, non-blocking > access to flaky network resources. When you bypass KIO and mount them > directly, you're undoing that protection. > > What kinds of things have you manually mounted and why? The mount in question is a samba share mounted over VPN when I work remotely at home. The problem with KIO is that it is not transparently available to all software, i.e. when opening a document with LibreOffice, it will be copied to a temporary directory, then copied back on save/quit. This removes the ability of LibreOffice to lock the file and detect concurrent changes of the source file. And it also breaks relation between the original file path and the path opened in the application: This is not what I expect to be transparency. Also, non-KDE programs cannot even parse the paths: Sometimes, KIO paths become directly passed to the program instead of copying the file to a local path first. CLI utilities cannot even be used to navigate KIO mounts. KIO should probably become a fuse module - which would then probably just introduce this exact reported behavior which KIO tries to avoid. KIO is nice if you exclusively only use KDE software - but that's quite unrealistic in practice. Also, it falls apart once you drop to the CLI level, which is what a lot of my workflow consists of. I'm actually using KIO for things like managing files over sftp remotely via Dolphin - and it works great then. But its field of use is very limited to me. Maybe comment #3 solves it for me. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #7 from Kai Krakow --- (In reply to Nate Graham from comment #5) > That's what kio-fuse was meant to solve. Do you have it installed? Ah ok, didn't know how it worked - and it was eventually kicked from the system previously by some conflict. I now reinstalled it and reloaded my systemd daemon. Observation: Opening files for non-KIO aware programs spawns a fuse mount. Looks like it doesn't do that for KIO-aware programs (at least I see no additional folders created in the mount directory). Let's see how I can use that for me. But I will still depend on NFS mounts from the local network, e.g. by backup repository will be mounted via an automounter (daily full system backup with borg). Usually, the NAS is available 24x7 but sometimes it will restart for updates - and that's when the plasmashell rarely but eventually blocks. Why does it look for network mounts that actually have no business with my user account, or does it? Any way to debug this when it happens? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #9 from Kai Krakow --- I'm not sure how that could even work. (a) it runs from a different session context, it's running from systemd system service while kio-fuse is a user session dbus service (b) this would imply that I could use `ls nfs://serverip/` which I obviously cannot (I tried, spoiler: doesn't work) Maybe that could be solved if I knew how KDE/KIO decides whether to use KIO and when to fall back to KIO fuse. How does this heuristic work? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #10 from Kai Krakow --- OTOH, I could try migrating to a borg client/server model instead of opening the repository via filesystem directly. This also decouples some security concerns as the borg service limits access patterns to those needed for repository access. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421131] Wayland: cursor lags under heavy CPU load
https://bugs.kde.org/show_bug.cgi?id=421131 --- Comment #14 from Kai Krakow --- I'd say that "loss of input events" should be actionable... (reported in comment #11) I don't care if mouse lags behind a little bit or jumps during CPU spikes, this also happens using X11. But it also loses input events (some keypresses are just discarded), and this particular problem seems very sensitive to even slight load spikes, and it was really distracting as texts I type had a lot of missing letters as if I couldn't type properly. I'm not sure if this has been fixed meanwhile because I switched back to kwin_x11 for that matter (and a lot of other quirks like context menus showing as windows etc). I'll give it another shot with 5.21: Seems at least a lot of quirks had been fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] New: Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 Bug ID: 441077 Summary: Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved Product: plasmashell Version: 5.21.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@kaishome.de Target Milestone: 1.0 Created attachment 140790 --> https://bugs.kde.org/attachment.cgi?id=140790&action=edit thread apply all bt SUMMARY Plasmashell tends to hang/completely freeze when a mounted network file system temporarily does not respond. Most of the times, the panels will recover after some minutes but sometimes they don't. I've now seen a freeze which didn't recover and I had to SIGKILL plasmashell to restart it, even `--replace` did not work. I'm not sure if a mounted file system was involved this time (see Additional Information below). Take note that the network mounts are completely unrelated, there's nothing on the panel that even loads data from it. In earlier versions this was also caused by plasma widgets loading data from network while the internet connection temporarily stalled. I've since removed all widgets that load data from network (like the weather widget). But I believe this incident may be caused by the disk usage warning plugin of plasma when it tries to access disk usage data from a non-responding mount. Conclusion: Plasma should not block and maybe wrap a timeout handler around queries that may potentially stall due to external reasons. However, this incident may be different. A plasma dev may have better insights. I'll attach a short and full gdb backtrace I was able to fetch from the hanging pid. Possible bug reports covering the mount-related issue but probably not a duplicate of this: #413110, #416972, #272361 STEPS TO REPRODUCE 0. The backtrace may not be about this particular hang: 1. Use network mounts somewhere below your home directory 2. Cut the network connection to stall access to these mounts 3. Observe plasmashell freezing and recovering minutes later OBSERVED RESULT Plasma panels stop responding to clicks and freeze with whatever content they did currently render. EXPECTED RESULT Plasma should detect timeouts and recover in one or another way, as a last resort it could kill itself and restart - which helped in this particular case: I SIGKILLed it and restarted it. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux (available in About System) KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This particular freeze may be related to this dmesg entry: [686470.331086] BUG: unable to handle page fault for address: 00020ee8 [686470.331091] #PF: supervisor write access in kernel mode [686470.331092] #PF: error_code(0x0002) - not-present page [686470.331093] PGD 0 P4D 0 [686470.331096] Oops: 0002 [#1] PREEMPT SMP [686470.331098] CPU: 1 PID: 1919 Comm: QSGRenderThread Not tainted 5.10.57-gentoo #1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441077] Plasmashell panels may freeze, usually unrelated but unresponsive NFS/SMB mounts are involved
https://bugs.kde.org/show_bug.cgi?id=441077 --- Comment #1 from Kai Krakow --- Created attachment 140791 --> https://bugs.kde.org/attachment.cgi?id=140791&action=edit thread apply all bt full -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #18 from Kai Krakow --- (In reply to tagwerk19 from comment #17) > Looks as if this is a long term issue... > Scroll down to the last posts in Bug 404057 Yep, this problem has already been deeply analyzed and is well understood. The referenced bug report includes a lot of thoughts, possible solutions, and also a few real improvements as patches - some of those were merged. There are also links to phabricator with extended discussion. I suggest to read that entirely to understand the problem (some later comments re-decide on previous thoughts). Sadly, I mostly lost interest in this issue in favor of other more important or personal stuff. I simply ditched baloo since then as I wasn't really using it anyway that much. But if anyone wants to take the effort in crafting any patches, they might want to start with implementing the mapping table from volume/subvolume UUID to a virtual device number - and that virtual device number would than be used instead of the real one. This way, a distinct file system would always show up as the same device number in baloo - no matter on which device node it appeared. It solves almost all of the problems mentioned here. I volunteer to mentor/help with such an implementation, I'm just too bad with Qt/KDE APIs to kickstart that myself. Later improvements should look at access patterns and how to optimize that, maybe LMDB can be used in a better way to optimize it for background desktop access patterns, otherwise it may need to be replaced with some other backend that's better at writing data to the database (aka, less scattering of data over time): LMDB is optimized for reads and appends, much less for random writes (but the latter is the most prominent access pattern for a desktop search index). So if we stay with LMDB, baloo needs to be optimized to prevent rewrites in favor of appends - without blowing up the DB size too much. It may mean to purge still existing data from the LMDB mmap in favor of a bigger continuous block of free DB memory. Also, aggressive write coalescing is needed to avoid fragmentation access patterns in filesystems. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 --- Comment #19 from Kai Krakow --- BTW: Such a UUID-to-deviceId mapping table would allow baloo to properly support most yet unsupported filesystems, probably also zfs. With such an idea implemented, the only requirement left to a supported filesystem would be that it has stable inodes across re-mounts/re-boots (most have, some don't) and supports reverse lookups (inode to path). The problematic design decision is how baloo identifies files: each file is assigned a devId/inodeId number (each lower 32-bit only, combined into a 64-bit fileId). If this magic number changes (that happens in zfs, btrfs, nfs...), the file appears as new. But neither Linux nor POSIX state anywhere that this can be used as an id to uniquely identify files - unless you never remount or reboot. Also, re-used inode numbers (especially after clipping at 32 bit) will completely mess up and confuse baloo. So this needs are multi-step fix: First (and most importantly) introduce virtual deviceIds by implementing a mapping table "volume/subvolId <-> virtualDeviceId" where virtualDeviceId would be a monotonically increasing number used uniquely throughout the index as a device id. Next step: Enlarge fileIds from 64 to 128 bit, so it can be crafted from 64-bit devid/inode without clipping/wraparound. On the pro side, such a mapping table would also allow to properly clean up index data from the DB for file systems no longer needed. Currently, baloo never knows if a file system would appear or doesn't. This could be implemented in one of the later steps as some sort of housekeeping optimizations. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 402154] Baloo reindexes everything after every reboot
https://bugs.kde.org/show_bug.cgi?id=402154 --- Comment #22 from Kai Krakow --- (In reply to tagwerk19 from comment #20) > (In reply to Kai Krakow from comment #18) > > ... I suggest to > > read that entirely to understand the problem ... > I've done my best :-) Thank you for the info! > > In: > > https://bugs.kde.org/show_bug.cgi?id=404057#c35 > > You have the the idea of an "Index per Filesystem" but then the idea seems I didn't... I explained why that would not work. > to have been put to the side. You mention "storage path" as a problem? Would > the way "local wastebaskets" are managed on mounted filesystems be a model? > They have to deal with the same issues as you've listed. The problem is that you would have do deal with proper synchronization when multiple databases are used. That is not just "find a writeable storage location and register this location somewhere". Also, you would need to have all these different DBs opened at the same time, and LMDB is a memory mapped database with random access patterns. So you'd multiply the memory pressure with each location, and that will dominate the filesystem cache. > https://phabricator.kde.org/T9805 This mentions "store an identifier per tracked device, e.g the filesystem UUID" which is probably my idea. Instead of using dev_id directly, the database should have a lookup table where filesystem UUIDs are stored as a simple list. The index of this list can be used as the new dev_id for the other tables. > Has a mention of "... inside encrypted containers", see this also in Bug > 390830. Encrypted containers should never be indexed in a global database as that would leak information from the encrypted container. The easiest solution would be to just not index encrypted containers unless the database itself is stored in an encrypted container - but that's also just an bandaid. Maybe encrypted containers should not be stored at all. Putting LMDB on an encrypted containers may have very bad side-effects on the performance side. > As background thoughts... > > Things like "Tags:" folders in Dolphin and incremental searches > when you type into Krunner depend on baloosearch being lightning fast. Having multiple databases per filesystem can only make this slower by definition because you'd need to query multiple databases. From my personal experience with fulltext search engines (ElasticSearch) I can only tell you that querying indexes and recombining results properly is a huge pita, and it's going to slow things way down. So the multiple database idea is probably a dead end. > It would be a shame to lose the ability to search for phrases as in > baloosearch Hello_Penguin > as opposed to > baloosearch "Hello Penguin" > > I'm guessing BTRFS usage is going to grow. The point is: Neither Linux nor POSIX state anywhere that a dev_id from stat() is unique across reboots or remounts. This is even less true for inode numbers with some remote filesystems or non-inode filesystems (where inode numbers are virtual and may be allocated from some runtime state). Those are not stable ids. At least for native Linux-filesystems we can expect inode numbers to be stable as those are stored inside the FS itself (the dev_id isn't but UUID is). On a side-note: In this context it would make sense to provide baloo as a system-wide storage and query service shared by multiple users, with an indexer running per user (to index encrypted containers). It's the only way to support these ideas: - safe access to encrypted containers - the database can be isolated from being readable by users (prevents information leakage) - solves the problem of multiple users indexing the same data multiple times - has capabilities to properly read UUIDs from filesystems/subvolumes (some FS only allow this for root) - can guard/filter which results are returned to users (by respecting FS ACLs and permission bits) - shared index location (e.g. /usr/share/docs) would be indexed just once On the contra side: - needs some sort of synchronization between multiple indexers (should work around race conditions that multiple indexers do not read and index the same files twice), could be solved by running the indexer within the system-wide service, too, but access to encrypted containers needs to be evaluated -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421131] Wayland: cursor lags under heavy CPU load
https://bugs.kde.org/show_bug.cgi?id=421131 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #9 from Kai Krakow --- I'm not sure if using setcap on kwin_wayland is correct: Now all desktop processes are running with FIFO/1 priority, probably because plasma forked from kwin_wayland. On supported kernels, it could try to use isochronous scheduling which is supported by some kernels and doesn't need special privileges: It works mostly like FIFO scheduling. But in the first place, it shouldn't spawn any processes while running with raised priority. Also, why doesn't it use rt-kit as a fallback? Or a small suid helper which checks if the parent process is kwin and then changes the priority? -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 435444] New: bluetooth is constantly scanning for services / devices
https://bugs.kde.org/show_bug.cgi?id=435444 Bug ID: 435444 Summary: bluetooth is constantly scanning for services / devices Product: Bluedevil Version: 5.21.3 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: now...@gmail.com Reporter: k...@kaishome.de CC: plasma-b...@kde.org Target Milestone: --- SUMMARY When the KDE session is running, my bluetooth dongle is constantly scanning for services and devices. The timeout is around 10s but it will immediately start again. The effect of this is that some bluetooth-connected devices have problems communicating correctly with my PC because inquiries are prioritized over other bluetooth traffic with the effect it seems to completely dominate the bluetooth connection. One affected device is the Xbox Elite 2 controller: While KDE is running, it is unstable and loses or delays input events. When KDE is stopped, the controller works just fine. After an [issue report in the Bluez Github project](https://github.com/bluez/bluez/issues/123) I was told that it is neither normal nor expected/recommended to have the dongle in permanent scan/inquiry mode because that traffic is priorities above other traffic which could explain my problem. It doesn't matter if I disable any KDE services (kdeconnect, bluetooth events, ...): The dongle is constantly discovering for 10s, then immediately starts again in a loop. Sometimes after I rebooted, the pattern may be different: 10s of discovering, 10s of non-discovering. This also seems to affect how well different devices may be able to connect via bluetooth: Without KDE running, my paired bluetooth devices connect immediately, with KDE running, the connection may take 30-60s before it is established. STEPS TO REPRODUCE 1. Enable bluetooth 2. Watch the output of btmgmt or btmon 3. Try with KDE and without KDE running OBSERVED RESULT With KDE running, watch btmgmt to see "hci0 type 1 discovering on" / "... off" is looping with 10s in "on" state, and <1s in "off" state. Without KDE running, no such behavior can be observed. Bluetooth devices have difficulties to properly communicate with low latency while inquiries are running, this may have a HUGE impact on SOME devices, especially devices requiring low latency (input, audio) come to mind here. EXPECTED RESULT KDE (or some component of it) should not constantly scan trying to discover devices. ADDITIONAL INFO The "Add device" wizard is not running. kdeconnect is running, it seems to have bluetooth integration. kio may be involved: https://github.com/KDE/bluedevil/blob/bb28472500c1292c9059b06af937ed51b4cb02f8/src/kio/bluetooth/kiobluetooth.cpp#L159 (the 10s timeout is quite an evidence) I already tried disabling pulseaudio and other bluetooth-integrated services. Only shutting KDE completely down resolves the issue. Maybe related: #308338, #401983 As per https://bugs.kde.org/show_bug.cgi?id=401983#c3 the kio thing looks promising. But how would I identify the process which is hammering the bluetooth:/ kio service? -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 435444] bluetooth is constantly scanning for services / devices
https://bugs.kde.org/show_bug.cgi?id=435444 --- Comment #1 from Kai Krakow --- Killing kdeconnectd seems to stop this behavior. -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 435444] bluetooth is constantly scanning for services / devices
https://bugs.kde.org/show_bug.cgi?id=435444 Kai Krakow changed: What|Removed |Added Version|5.21.3 |5.21.4 -- You are receiving this mail because: You are watching all bug changes.
[Bluedevil] [Bug 435444] bluetooth is constantly scanning for services / devices
https://bugs.kde.org/show_bug.cgi?id=435444 --- Comment #3 from Kai Krakow --- Are there instruction on how to properly create a dbus monitor log? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 428770] New: Dolphin crashed when browsing cifs mounts
https://bugs.kde.org/show_bug.cgi?id=428770 Bug ID: 428770 Summary: Dolphin crashed when browsing cifs mounts Product: dolphin Version: 20.08.2 Platform: Gentoo Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: k...@kaishome.de CC: kfm-de...@kde.org Target Milestone: --- Application: dolphin (20.08.2) Qt Version: 5.15.1 Frameworks Version: 5.74.0 Operating System: Linux 5.4.73-gentoo x86_64 Windowing system: X11 Distribution: "Gentoo Base System release 2.7" -- Information about the crash: - What I was doing when the application crashed: I have some folders mounted over CIFS from a remote VPN. When browsing folders (e.g., clicking multiple folders in a short time), Dolphin crashes. This is probably some timing issue, I've never seen it crashing on local folders. The crash can be reproduced sometimes. -- Backtrace: Application: Dolphin (dolphin), signal: Segmentation fault Content of s_kcrashErrorMessage: (null) [New LWP 2867442] [New LWP 2867443] [New LWP 2867451] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". 0x7ff2454d31ef in __GI___poll (fds=fds@entry=0x7ffd4f79c428, nfds=nfds@entry=1, timeout=timeout@entry=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 [Current thread is 1 (Thread 0x7ff23e62c8c0 (LWP 2867440))] Thread 4 (Thread 0x7ff22aa82640 (LWP 2867451)): #0 __GI___getdents64 (fd=4, buf=buf@entry=0x7ff21410d6f0, nbytes=) at ../sysdeps/unix/sysv/linux/getdents64.c:32 #1 0x7ff2454a7b15 in __GI___readdir64 (dirp=dirp@entry=0x7ff21410d6c0) at ../sysdeps/posix/readdir.c:65 #2 0x7ff24535f678 in walkDir (dirPath=..., countHiddenFiles=countHiddenFiles@entry=false, countDirectoriesOnly=countDirectoriesOnly@entry=false, dirEntry=, dirEntry@entry=0x7ff21400dc18, allowedRecursiveLevel=allowedRecursiveLevel@entry=0) at /var/tmp/portage/kde-apps/dolphin-20.08.2/work/dolphin-20.08.2/src/kitemviews/private/kdirectorycontentscounterworker.cpp:53 #3 0x7ff24535f93d in walkDir (dirPath=..., countHiddenFiles=countHiddenFiles@entry=false, countDirectoriesOnly=countDirectoriesOnly@entry=false, dirEntry=0x7ff21400dc18, dirEntry@entry=0x0, allowedRecursiveLevel=allowedRecursiveLevel@entry=1) at /var/tmp/portage/kde-apps/dolphin-20.08.2/work/dolphin-20.08.2/src/kitemviews/private/kdirectorycontentscounterworker.cpp:92 #4 0x7ff24535fa7a in KDirectoryContentsCounterWorker::subItemsCount (path=..., options=...) at /usr/include/qt5/QtCore/qarraydata.h:61 #5 0x7ff24535fb57 in KDirectoryContentsCounterWorker::countDirectoryContents (this=0x55e06c580b90, path=..., options=...) at /var/tmp/portage/kde-apps/dolphin-20.08.2/work/dolphin-20.08.2/src/kitemviews/private/kdirectorycontentscounterworker.cpp:133 #6 0x7ff2432918ce in QObject::event (this=0x55e06c580b90, e=0x55e06cf0b2c0) at /var/tmp/portage/dev-qt/qtcore-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/corelib/kernel/qobject.cpp:1314 #7 0x7ff243de9142 in QApplicationPrivate::notify_helper (this=this@entry=0x55e06c00fac0, receiver=receiver@entry=0x55e06c580b90, e=e@entry=0x55e06cf0b2c0) at /var/tmp/portage/dev-qt/qtwidgets-5.15.1/work/qtbase-everywhere-src-5.15.1/src/widgets/kernel/qapplication.cpp:3630 #8 0x7ff243df22e1 in QApplication::notify (this=0x7ffd4f79e5a0, receiver=0x55e06c580b90, e=0x55e06cf0b2c0) at /var/tmp/portage/dev-qt/qtwidgets-5.15.1/work/qtbase-everywhere-src-5.15.1/src/widgets/kernel/qapplication.cpp:3154 #9 0x7ff243263998 in QCoreApplication::notifyInternal2 (receiver=0x55e06c580b90, event=0x55e06cf0b2c0) at /var/tmp/portage/dev-qt/qtcore-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/corelib/kernel/qcoreapplication.cpp:1063 #10 0x7ff2432666f3 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x55e06c55e9d0) at /var/tmp/portage/dev-qt/qtcore-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/corelib/kernel/qcoreapplication.cpp:1817 #11 0x7ff2432bdaf4 in postEventSourceDispatch (s=0x7ff214004fe0) at /var/tmp/portage/dev-qt/qtcore-5.15.1-r1/work/qtbase-everywhere-src-5.15.1/src/corelib/kernel/qeventdispatcher_glib.cpp:277 #12 0x7ff240fc427d in g_main_dispatch (context=0x7ff214000c20) at ../glib-2.64.5/glib/gmain.c:3309 #13 g_main_context_dispatch (context=context@entry=0x7ff214000c20) at ../glib-2.64.5/glib/gmain.c:3974 #14 0x7ff240fc44f8 in g_main_context_iterate (context=context@entry=0x7ff214000c20, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib-2.64.5/glib/gmain.c:4047 #15 0x7ff240fc458f in g_main_context_iteration (context=0x7ff214000c20, may_block=may_block@entry=1) at ../glib-2.64.5/glib/gmain.c:4108 #16 0x7ff2432bd882 in QEventDispatcherGlib::processEvents (this=0x7ff214000b60, flags=...) at /var/tmp/portage/d
[plasmashell] [Bug 377588] plasma panels not shown after reboot
https://bugs.kde.org/show_bug.cgi?id=377588 --- Comment #6 from Kai Krakow --- I can still reproduce it on a real 2-monitor system at work: After an update to Plasma 5.20, one panel was gone, the other moved over to the second monitor. When I switch between Wayland session and X11 session, I can reproduce that behavior. I didn't yet confirm this behavior: In the office, someone disconnected one monitor from my workstation while a Wayland session was running. When I returned to the office later with the monitor already reconnected, both monitors seemed to have swapped places, and one panel was gone. Meanwhile, on the original system, I had no more problems: The configuration has been stable there for a while now. But I cannot use Wayland there, only X11. So I cannot confirm if the issue still exists on that system. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 422282] Crash inKFileItemModel::removeItems() when using the tree view mode of the details view
https://bugs.kde.org/show_bug.cgi?id=422282 --- Comment #19 from Kai Krakow --- Following up on my original report https://bugs.kde.org/show_bug.cgi?id=428770: When the problem occurs, I usually see every folder entry duplicated. I only observed that in folder tree mode when expanding the tree on a sub folder. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479859] New: select-and-drag text crashes some or all non-KDE apps in wayland
https://bugs.kde.org/show_bug.cgi?id=479859 Bug ID: 479859 Summary: select-and-drag text crashes some or all non-KDE apps in wayland Classification: Plasma Product: kwin Version: 5.27.10 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: k...@kaishome.de Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Browse a web page in Chrome 2. Select text with the mouse 3. Try to drag the selected text across the screen OBSERVED RESULT The desktop freezes for a short amount of time ramping up IO, then the application (source of the drag operation) crashes. EXPECTED RESULT The application should not crash, obviously. But also, I should be able to drag the text to another window, or drag the text from one input field to another. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux 2.14, kernel 6.6.9, Wayland (available in About System) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION If this happens by accident, unsaved work gets lost thus raising bug priority. Also, this or a similar crash happens when dragging the last open Chrome tab out of its window. Apps that actually drag text as text seem to not be affected, e.g. I could drag text from Sublime Text to KWrite. So this may be limited to the Chrome-family of browsers and Electron apps. Or there is an issue with multi-format clipboard contents, e.g. dragging text from the browser can insert HTML and plain text, or dragging a browser tab can insert the tab in another browser or the URL in a text editor. Chrome creates a crashdump with SIGTRAP, but there's no backtrace. No such crash seems to occur with X11. -- You are receiving this mail because: You are watching all bug changes.
[filelight] [Bug 477569] New: Filelight crashes when deleting a directory via context menu
https://bugs.kde.org/show_bug.cgi?id=477569
Bug ID: 477569
Summary: Filelight crashes when deleting a directory via
context menu
Classification: Applications
Product: filelight
Version: 23.08.3
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: k...@kaishome.de
CC: martin.sandsm...@kde.org
Target Milestone: ---
Application: filelight (23.08.3)
Qt Version: 5.15.11
Frameworks Version: 5.112.0
Operating System: Linux 6.6.2-gentoo x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.27.9 [KCrashBackend]
-- Information about the crash:
As the title says:
1. Open a folder in file light, e.g. right-click in dolphin on a folder and
choose "open in filelight".
2. Then let the directory scan complete.
3. Right click on a folder and choose "delete".
A dialog box appears asking for confirmation but then filelight immediatly
crashes even before I have a chance to confirm or cancel the dialog.
The crash can be reproduced every time.
-- Backtrace:
Application: Filelight (filelight), signal: Aborted
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#7 0x563cf40b13ef in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#8 0x563cf4063922 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#9 0x563cf404d4ad in __GI_abort () at abort.c:79
#10 0x563cf46920fd in qt_message_fatal (message=...,
context=) at
/var/tmp/portage/dev-qt/qtcore-5.15.11-r1/work/qtbase-everywhere-src-5.15.11/src/corelib/global/qlogging.cpp:1919
#11 QMessageLogger::fatal(char const*, ...) const
(this=this@entry=0x7ffc5cdbfc70, msg=msg@entry=0x563cf61bfc68 "Object %p
destroyed while one of its QML signal handlers is in progress.\nMost likely the
object was deleted synchronously (use QObject::deleteLater() instead), or the
application is running a nested e"...) at
/var/tmp/portage/dev-qt/qtcore-5.15.11-r1/work/qtbase-everywhere-src-5.15.11/src/corelib/global/qlogging.cpp:898
#12 0x563cf6082756 in QQmlData::destroyed(QObject*) (this=,
object=0x563cf822fac0) at
/var/tmp/portage/dev-qt/qtdeclarative-5.15.11-r2/work/qtdeclarative-everywhere-src-5.15.11/src/qml/qml/qqmlengine.cpp:1965
#13 0x563cf48c7688 in QObject::~QObject() (this=this@entry=0x563cf822fac0,
__in_chrg=) at
/var/tmp/portage/dev-qt/qtcore-5.15.11-r1/work/qtbase-everywhere-src-5.15.11/src/corelib/kernel/qobject.cpp:1019
#14 0x563cf3d6ac7a in QQuickAction::~QQuickAction()
(this=this@entry=0x563cf822fac0, __in_chrg=) at
/var/tmp/portage/dev-qt/qtquickcontrols2-5.15.11/work/qtquickcontrols2-everywhere-src-5.15.11/src/quicktemplates2/qquickaction.cpp:360
#15 0x563cec4e049b in
QQmlPrivate::QQmlElement::~QQmlElement() (this=0x563cf822fac0,
__in_chrg=) at /usr/include/qt5/QtQml/qqmlprivate.h:144
#16 QQmlPrivate::QQmlElement::~QQmlElement()
(this=0x563cf822fac0, __in_chrg=) at
/usr/include/qt5/QtQml/qqmlprivate.h:144
#17 0x563cf48c1762 in QObjectPrivate::deleteChildren()
(this=this@entry=0x563cf8228770) at
/var/tmp/portage/dev-qt/qtcore-5.15.11-r1/work/qtbase-everywhere-src-5.15.11/src/corelib/kernel/qobject.cpp:2137
#18 0x563cf48c7a24 in QObject::~QObject() (this=this@entry=0x563cf82286b0,
__in_chrg=) at
/var/tmp/portage/dev-qt/qtcore-5.15.11-r1/work/qtbase-everywhere-src-5.15.11/src/corelib/kernel/qobject.cpp:1115
#19 0x563cf6662ab2 in QQuickItem::~QQuickItem()
(this=this@entry=0x563cf82286b0, __in_chrg=) at
/var/tmp/portage/dev-qt/qtdeclarative-5.15.11-r2/work/qtdeclarative-everywhere-src-5.15.11/src/quick/items/qquickitem.cpp:2389
#20 0x563cf3d87e2f in QQuickControl::~QQuickControl()
(this=this@entry=0x563cf82286b0, __in_chrg=) at
/var/tmp/portage/dev-qt/qtquickcontrols2-5.15.11/work/qtquickcontrols2-everywhere-src-5.15.11/src/quicktemplates2/qquickcontrol.cpp:1009
#21 0x563cf3d67acb in QQuickAbstractButton::~QQuickAbstractButton()
(this=this@entry=0x563cf82286b0, __in_chrg=) at
/var/tmp/portage/dev-qt/qtquickcontrols2-5.15.11/work/qtquickcontrols2-everywhere-src-5.15.11/src/quicktemplates2/qquickabstractbutton.cpp:491
#22 0x563cec4e237d in QQuickMenuItem::~QQuickMenuItem()
(this=0x563cf82286b0, __in_chrg=) at
/var/tmp/portage/dev-qt/qtquickcontrols2-5.15.11/work/qtquickcontrols2-everywhere-src-5.15.11/include/QtQuickTemplates2/5.15.11/QtQuickTemplates2/private/../../../../../src/quicktemplates2/qquickmenuitem_p.h:58
#23 QQmlPrivate::QQmlElement::~QQmlElement()
(this=0x563cf82286b0, __in_chrg=) at
/usr/include/qt5/QtQml/qqmlprivate.h:144
#24 QQmlPrivate::QQmlElement::~QQmlElement()
(this=0x563cf82286b0, __in_chrg=) at
/usr/include/qt5/QtQml/qqmlprivate.h:144
#25 0
[kwin] [Bug 472182] New: kwin_wayland crashed probably while calling into pipewire
https://bugs.kde.org/show_bug.cgi?id=472182 Bug ID: 472182 Summary: kwin_wayland crashed probably while calling into pipewire Classification: Plasma Product: kwin Version: 5.27.4 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: k...@kaishome.de Target Milestone: --- Created attachment 160248 --> https://bugs.kde.org/attachment.cgi?id=160248&action=edit thread apply all bt full SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Put the system under high load (memory pressure and high IO, e.g. compiling a big package) 2. Use the desktop 3. Some actions (switching a task, hovering icons, copying to clipboard) suddenly freeze the desktop including the mouse pointer OBSERVED RESULT When the desktop froze, I can instantly observe high IO thrashing. The desktop has been under load before (both IO and RAM) but I could still use it smoothly. After 1-2 minutes, the disk thrashing stops, the screens go black, then my session restarts empty. IO thrashing can probably be explained because a lot of processes become killed at the same time, causing swapping and memory cleanup, at the same time, systemd-coredump collects debug info to create the backtrace. So I think IO thrashing and RAM pressure is not directly causing the problem. This feels more like a race condition caused by system latency spikes. EXPECTED RESULT The system should freeze shortly (in the worst case) and then recover. In the best case, it should just become slow to respond and the mouse pointer should not freeze - but wayland seem to be much more susceptible to system load than Xorg, both for input latency and rendering. This may create an impression that the crash is seemingly related to the high system load. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo, kernel 6.1.28 (available in About System) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION (this is the second of two identical backtraces, the previous backtrace was recorded 1 month ago, gdb backtrace attached) PID: 2479 (kwin_wayland) UID: 1000 (kakra) GID: 1000 (kakra) Signal: 11 (SEGV) Timestamp: Wed 2023-07-12 10:25:46 CEST (1h 0min ago) Command Line: /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/1000/xauth_BvNgWv --xwayland Executable: /usr/bin/kwin_wayland Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service Unit: user@1000.service User Unit: plasma-kwin_wayland.service Slice: user-1000.slice Owner UID: 1000 (kakra) Boot ID: d2c6891dae64413da51cd66ab5c9cd05 Machine ID: 5047221968d9d69177b931b5000a Hostname: arbeitsplatz1 Storage: /var/lib/systemd/coredump/core.kwin_wayland.1000.d2c6891dae64413da51cd66ab5c9cd05.2479.168915034600.zst (inaccessible) Message: Process 2479 (kwin_wayland) of user 1000 dumped core. Module libpipewire-module-session-manager.so without build-id. Module libpipewire-module-metadata.so without build-id. Module libpipewire-module-adapter.so without build-id. Module libpipewire-module-client-device.so without build-id. Module libpipewire-module-client-node.so without build-id. Module libpipewire-module-protocol-native.so without build-id. Module libspa-dbus.so without build-id. Module libqtquicktemplates2plugin.so without build-id. Module libplasmacomponentsplugin.so without build-id. Module libqtquickcontrolsplugin.so without build-id. Module libqmlplugin.so without build-id. Module libplasmaextracomponentsplugin.so without build-id. Module libqquicklayoutsplugin.so without build-id. Module libOpenGL.so.0 without build-id. Module libKF5Declarative.so.5 without build-id. Module libKF5QuickAddons.so.5 without build-id. Module libKF5PlasmaQuick.so.5 without build-id. Module libcorebindingsplugin.so without build-id. Module libwindowplugin.so without build-id. Module libspa-journal.so without build-id. Module libspa-support.so without build-id. Module libwebpdemux.so.2 without build-id. Module libwebpmux.so.3 without build-id. Module libqweb
[plasmashell] [Bug 375951] locally integrated menus
https://bugs.kde.org/show_bug.cgi?id=375951 --- Comment #38 from Kai Krakow --- (In reply to Adam from comment #34) > I would love to see LIM. Having the two bars is a waste of space imo. > > I tried with the menu button before, but then you don't see which menus are > available, and there is the additional click, after which you have to find > the menu you are looking for, and move the mouse. > > It would be a bit faster with the hiding menu in the title bar. But still, > there would be the problem of not seeing everything from the start, > discoverability, and having to hover the title bar before being able to move > to the right menu. > Therefore I would prefer to have menu and title side by side. If there is > little space, it could degenerate to a hamburger or traditional 2 line setup. Do we really need a title at all? Most multi-document apps today are tabbed anyways, so we have the document title in the tab bar. And it's pretty clear which application is which by just looking at it's appearance. Why duplicate the title in the decoration when we already have it in the task bar? I already made my decoration "title" bar as small as possible because I'm rarely interested in what the title is - and I can already drag most windows by dragging from some blank space in the window. I'm not even sure if classical menu items should be in a title bar at all: It's not too easy to point at them unless the window is maximized (because then the mouse pointer would stop at the top of the screen). So menu bars should be at the top of the screen and change when I switch the window. I'm seeing the "title" bar to be more useful for items like some often used functions of the application (the core function if you want so). And by eliminating the menu from it completely, there'd also be space for a document title. But yes, if menu items right within the window should be the way to go, I'd rather see the expanded list of items across the decoration instead of a title, and instead of hiding away possibly important menu items in a hamburger menu. I consider the application title or document title the least important thing to have in the decoration, as usually that's duplicated to the task bar and tab bars anyways. But that's probably not true for all applications. The current miniature hamburger menu is just a pita to use - did you ever try to click it without precise targeting the mouse pointer at it? A temporary solution could be to make the hamburger icon just a real button that says "Menu" or "Application Name". PS: I almost stopped using menu bars. Either using keyboard shortcuts or avoid using such applications. However, that's not always possible. And for some reason most GTK apps ignore it anyways and show a menu bar - if at least that would be colored like the decorations... May I still dream? ;-) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 364947] KMail crashed while clicking through mails
https://bugs.kde.org/show_bug.cgi?id=364947 Kai Krakow changed: What|Removed |Added Resolution|WAITINGFORINFO |UNMAINTAINED Status|NEEDSINFO |RESOLVED --- Comment #3 from Kai Krakow --- I'm no longer using kmail due to its instability, potential to eat my mails, bad impact on system performance, and it being unusable on HiDPI monitors. I may try again sometime in the future but currently I'm going with using Mailspring and web mailers. Resolving as unmaintained. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421131] Wayland: cursor lags under heavy CPU load
https://bugs.kde.org/show_bug.cgi?id=421131 --- Comment #11 from Kai Krakow --- BTW: It's not only the mouse cursor lagging, key presses are also simply not detected. And this even happens with a low average CPU load if you just have some processes stuck in IO for a few ms: I was thinking I'm not able to properly spell words any longer with this because every now and then, a letter goes missing while typing. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 141267] wallet password dialog should stay in front
https://bugs.kde.org/show_bug.cgi?id=141267 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #22 from Kai Krakow --- (In reply to RJVB from comment #21) > I can see how that could be an advantage to some people, but it'd be a no-go > for me. If something wants me to enter a password > > 1) I want to be able to let that pend while I finish something else (could > be watching a movie) > 2) I want to be able to move the dialog, for instance to see who is > requesting my password I think the point here is rather about focus stealing by other applications. If a password dialog pops up and I start typing in it, I don't want other applications to steal the focus. I had situations in the past when I started two applications by clicking two icons. The first one started fast, and the password dialog popped up, I then started entering by password while the second application finally started, stole the focus with a cursor in a chat window, and me just typing the password in the chat window and hitting enter unnoticed. A full screen modal dialog prevents that but I'm with your opinion that we should not have this kind of modal full screen dialog. Rather, the password dialog should ensure nothing can steal its focus while the cursor sits in its input field. If I manually unfocus the input field, I don't actually care about what the dialog does, letting it pend in the background, the same as you do: to finish a task or find what is actually requesting the password. So while the password input field is in focus, the dialog should ensure two things: 1. Not letting some other window steal its focus (maybe this needs support from the window manager) 2. Stay in front (so it doesn't go unnoticed behind other windows popping up shortly after it) But it should also not grab focus unconditionally. Example: I'm currently typing in an editor or chat application, suddenly a password dialog pops up, grabbing focus, and I would enter a wrong password. In the best case, it would just ask again, in the worst case, it may lock an account or fail an operation you didn't want to fail. So if I am actively typing somewhere currently, the password dialog should not focus itself (or at least not focus the password field) but rather just display on top, maybe with some visual distraction like flashing the taskbar item. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #77 from Kai Krakow --- For me it seems to be fixed or at least works as expected after I disabled the kscreen service in the system settings. With each plasma updates, the behavior seems to change in random and unpredictable ways. Disabled kscreen, and now: Turing off my main monitor moves then panels over to the other screen, turning it back on moves them back, repeatable. The downside is: Windows won't move over to the other screen and I cannot access them except moving them blindly over with Alt+mouse click. But that's a minor issue because I either run both monitors or none. At least it's not messing with backgrounds and window positions. But then again: Why do the panels actually still move? If disabling kscreen prevents the windows being moved and that part of the desktop actually still being included in the usable mouse area - why do the panels move? Is it possible that plasma panels use a completely different event source and that's causing all of the mess? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484323] High CPU load of kwin_x11 when locking or turning off the screen
https://bugs.kde.org/show_bug.cgi?id=484323 --- Comment #38 from Kai Krakow --- (In reply to Kai Krakow from comment #36) > Is this caused by the blur effects of plasma and konsole? It may have been resolved, at least partially, by https://github.com/NVIDIA/open-gpu-kernel-modules/commit/1795a8bb20fe09f9939ca3e82d76791f5741e467. It mentions KDE here: https://www.nvidia.com/Download/driverResults.aspx/228410/en-us/ I'm using the 555 driver, and since the update, high CPU usage /while/ using the system has gone down. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] Some windows are painted black on X11, processes freeze
https://bugs.kde.org/show_bug.cgi?id=466771 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #32 from Kai Krakow --- I've first seen this on Plasma 6 with Gen4 Intel iGPU using wayland. It doesn't happen with Xorg on that same system. Maybe related: On my NVIDIA system, the same thing happens with wayland quite easily if I run wayland during gaming/streaming with OBS. It's really bad, I've gone back to Xorg. But even with Xorg, kwin_x11 and plasma-shell often crash and restart after 2+ hours, causing severe stutters in game and causing framedrops in recording/streaming. When this happens, plasmashell already uses 2 GB of VRAM. I really don't know why it eats so much VRAM, and it probably crashes because it fails to allocate anything more. VRAM usage of plasmashell it absurd, even when idle, it already uses 800+ MB, after some light usage, it easily uses 1+ GB already. The nvidia-drivers can do some cleanup every once in a while (a feature called "CPMM", please ask NVIDIA developers about the details, I'm not allowed to disclose the tuning parameters: it's active by default with 10min cleanup interval). It brings usage down from 800 MB initially to only 170 MB (using 15 seconds cleanup interval [1]). But that only means that plasmashell piles up a lot of render surfaces or render buffers it never cleans up on its own. This feature only works for GL, so if you switch to Vulkan using "kcmshell6 qtquicksettings", it shows the bad behavior again. Unfortunately, using the software renderer no longer works in Plasma 6: it renders icons to the wrong positions or completely removes them from rendering as soon as you hover the mouse over them. But in this mode, plasmashell uses only 4 MB of VRAM and I'm seeing no negative performance impact. In Plasma 5, this has been the game changer. Now with Plasma 6, the system isn't really usable if you stress the system with VRAM allocations as games usually do. And that's not limited to NVIDIA, it happens on Intel iGPUs too, and usually very quickly because of the low amount of shared VRAM. And with wayland, all of this is handled exceptionally bad, Xorg is a little more forgiving. While wayland works beautifully (ultra-smooth desktop, proper scaling etc) for light desktop usage, everything causes havoc if you do some real work like having lots of open windows on multiple monitors (4 in my instance), rendering or gaming, especially with OBS. Plasma starts to fight with every process in the system over GPU resources. There's no longer an option to use software rendering because rendering is just broken with it. I really don't need hardware accelerated rendering for the plasmashell: In the end, it's just a bar to switch between applications, and launcher and notification manager. But it's the main consumer of GPU resources on a KDE desktop, and it fights for it really hard, hurting performance more than what is gained by hardware rendering. Currently I can work around it by using QSV with OBS (instead of NVENC), limiting my main game VRAM usage through DXVK and using a short CMPP interval only for plasmashell. But that only helps short term, longer sessions are really borked, and after more than 2 days of usage, I'd rather need to reboot before trying anything else. Also, it's a little more stable by using the NVIDIA open kernel drivers: they seem to handle VRAM a little different. But even if drivers can or should fix it, VRAM usage of plasmashell is still absurdly high and it will hurt performance for gaming - no matter what a driver can do. I hope this gets fixed sooner than later, that would be great. :-) [1]: This low interval has some unwanted side-effects in OBS as it cleans up OBS render resources, too, leading to repeated frametime spikes during recording or streaming. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] Some windows are painted black on X11, processes freeze
https://bugs.kde.org/show_bug.cgi?id=466771 --- Comment #35 from Kai Krakow --- (In reply to Ben Hay from comment #33) > Even swapped my NVidia card for AMD. Bug still occured, although it takes a > little longer to manifest. > > Finally I uninstalled the latte-dock package. > Plasma is stable again. This is probably because latte-dock is a heavy user of GPU resources, probably in terms of VRAM. I don't think this is caused by latte-dock per se, there's something generally going wrong deeper in the stack. Same probably applies to plasmashell. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #21 from Kai Krakow --- @Martin I think your bug report is already really about this issue: Re-indexing all files over and over again and consuming a lot of memory and IO that way. The performance aspects of this are already covered by another bug report: https://bugs.kde.org/show_bug.cgi?id=356357 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 Kai Krakow changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=356357 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 356357] Continous index flushing with fdatasync degrades interactive performance
https://bugs.kde.org/show_bug.cgi?id=356357 Kai Krakow changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=404057 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 400704] Baloo indexing I/O introduces serious noticable delays
https://bugs.kde.org/show_bug.cgi?id=400704 Kai Krakow changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=404057 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 Kai Krakow changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=400704 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #23 from Kai Krakow --- I'll have a look at that soon. First I'd like to get the "Reduce stack pressure" patch upstreamed (also as a learning curve because this is my first KDE contribution). I've uploaded it to Phabricator and already received review feedback. I have some ideas what may be causing this problem (loss of ContentIndexingDB) which in turn is probably the immediate cause of DB growing and increasing IO pressure. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #25 from Kai Krakow --- Yes, that's my plan. But I'd like to refine them a bit first. Especially turning fsync() off seems to involve a big controversy discussion about whether this should be done or not. So I will research the side effects a little more and try to come up with a better solution. FWIW, I'd like to submit a read-ahead patch next (fixes low-memory problems), and then I'd like to fix the problem that ContextIndexingDB becomes dropped for some reason which is, at least for Martin and me, the most prominent origin of always increasing IO-pressure and memory usage. Later I'll look into reducing the transaction commits dynamically which should relax the fsync problem, and maybe even sizing the mmap dynamically (which should me possible according to some first research). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 Kai Krakow changed: What|Removed |Added Attachment #122918|0 |1 is obsolete|| --- Comment #26 from Kai Krakow --- Comment on attachment 122918 --> https://bugs.kde.org/attachment.cgi?id=122918 Reduce stack pressure Stack pressure patch obsoleted by https://phabricator.kde.org/D24502 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 Kai Krakow changed: What|Removed |Added Attachment #122925|0 |1 is obsolete|| --- Comment #27 from Kai Krakow --- Comment on attachment 122925 --> https://bugs.kde.org/attachment.cgi?id=122925 Prepare simpler coding of environment flags Has been merged into master -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #28 from Kai Krakow --- (In reply to Kai Krakow from comment #19) > After testing this a few days, with my patches it works flawlessly: No > performance impact, krunner finds result immediately without thrashing the > HDD, etc. That is, until you reboot: While with the patches it has no longer > any perceived negative impact on desktop responsiveness, I see that Baloo > still re-indexes all files. > > Steps to reproduce: > > 1. Start baloo for the first time (aka "remove your index") > 2. Let it complete a full indexing cycle > 3. Observe "balooctl indexSize" to see that there's no file left to index > 4. Also observe that it has data in "ContentIndexingDB" > 5. Reboot > 6. Observe "balooctl indexSize" to see that "ContentIndexingDB" changed back >to 0 bytes > 7. Observe "balooctl status" and wait until it finished checking for missing >files > 8. Observe both commands to see how baloo now refills the ContentIndexingDB >and adds all your files to the index again, resulting in double the amount >of files after finishing the second run > 9. From now on, on every reboot, the index only grows, constantly forgetting >the ContentIndexDB and re-adding all files. > > This behavior is with and without my patches. > > @Martin Is this what you've seen, too? Following up with more details: The problem seems to be the following: After reboot, the indexer finds all files as changed. For every file in the index, it will log to stdout/stderr: "path to file" id seems to have changed. Perhaps baloo was not running, and this file was deleted + re-created This results in a lot of transactions to the database, blowing it up in size (due to its lock-free implementation it appends to the database before freeing the old data) and creating high IO pressure due to a lot of fsync calls going on in short succession. What follows: After removing all the seemingly changed files from the database, it re-indexes all those files. This in turn appends to the database again it seems, probably because its unlikely to find big enough "holes" at the beginning of the database: Although a lot of data has been removed, it has probably been filled with meta data updates, leaving no space to put back in the content index data. This access patterns adds up after some time, spreading out data more and more, leading to very random access patterns. The kernel will start to struggle with the mmap because it constantly swaps in new pages: Due to the random and wide spread access patterns, it becomes more and more less likely that memory pages are already swapped in. Access behavior becomes more and more seeky, the database contents could be said to be too fragmented. This will introduce high desktop latency because baloo will start to dominate the cache with its mmap. After all, we should keep in mind that LMDBs design is made for systems primarily running only the database, but not mixed with desktop workloads. The phabricator site already has some valuable analysis and ideas of this which I collected here: https://phabricator.kde.org/T11859 Thinks that currently help here a lot: - Remove fsync from baloo via patch (this seems to have the biggest impact) - Limiting the working set memory baloo can use by using cgroups Removing fsync from baloo could mean that the database is not crash-safe. Thus, I suggest to not use my fsync patch upstream until extensive testing of such situations (I do not know how to do that, it's a tedious task depending on a vast amount of factors) or until someone comes up with some clever recovery/transaction idea. Maybe the LMDB author has some more insight on this. Limiting memory with cgroups helps because cgroups can limit RAM usage by accounting for both heap and cache usage: It effectively hinders baloo from dominating the cache and thus impacting desktop performance too much. The read-ahead patch reduces additional pressure on the cache occupancy. It should also be possible to use madvise()/fadvise() to actively instruct the kernel that baloo no longer uses some memory or doesn't plan on doing so in the future. I'm not sure if baloo and/or LMDB use these functions or how they use them. Also, I wonder if LMDB uses MAP_HUGETLB. It may be worth checking if flipping this setting improves or worsens things because I can think of different scenarios: 1. hugetlb uses 2 MB page size which could reduce the IOPS needed to work on spatially near data in the DB (good) 2. 2 MB page size could increase the IO throughput needed when paging DB data in, thus negatively impacting the rest of the system (bad) 3. LMDB should grow the database in bigger chunks to reduce external fragmentation of the index file, hugetlb could help that (unde
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #29 from Kai Krakow --- During the re-index job after reboot, baloo shows very strange behavior when evaluating the indexSize: $ balooctl indexSize File Size: 6,83 GiB Used: 25,48 MiB PostingDB: 1.018,96 MiB 3998.360 % PositionDB: 1,73 GiB 6957.158 % DocTerms: 909,35 MiB 3568.271 % DocFilenameTerms: 131,17 MiB 514.700 % DocXattrTerms: 4,00 KiB 0.015 % IdTree: 31,09 MiB 121.980 % IdFileName: 107,08 MiB 420.172 % DocTime: 67,19 MiB 263.642 % DocData: 67,14 MiB 263.473 % ContentIndexingDB: 3,99 MiB15.650 % FailedIdsDB:0 B 0.000 % MTimeDB: 12,53 MiB49.172 % Also, "File Size" increases with every reboot while "Used" stays around the same when compared after baloo has decided to idle. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #31 from Kai Krakow --- As far as I understand from researching the discussions in phabricator, this problem won't be easy to fix as it is baked into the design decision that defined the database scheme. Based on the fact that the DocId (which is used to find if a file still exists, or changed, or just moved unmodified) is a 64-bit value which is actually made of a 32-bit st_dev (device id) and 32-bit ino (inode number), I see two problems here: 1. btrfs uses 64-bit inode numbers, at some point, numbers will overflow and the baloo database becomes confused. 2. multi-dev btrfs (and I think you also use that, as I do) may have an unstable st_dev number across reboots, resulting in changed DocIds every once in a while after reboot The phabricator discussions point out that other (primarily network) file systems suffer the same problem: They have unstable st_dev values maybe even after reconnect. User space file systems even depend on mount order for the st_dev value. Changing this is no easy task, it would require a format change which either invalidates your DB, or it needs migration. So I'm currently evaluating if it makes sense to switch to a key/value store that doesn't rely on mmap (as it has clear downsides on a typical desktop system). This would allow to easily change the database scheme in the same step as the index would've to be recreated anyways. I'm currently digging my nose into Facebook's RocksDB, it looks mostly good except that it was optimized solely around flash-based storage. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #32 from Kai Krakow --- (In reply to Martin Steigerwald from comment #30) > I believe this bug is at > least about two or three independent issues, but as you told, let's have it > about the re-indexing files thing. I bet getting rid of needlessly > re-indexing files will be one of the most effective to sort out performance > issues with Baloo. I changed bug subject accordingly. That's why I started a task to better distinguish between which problem is what in Phabricator: https://phabricator.kde.org/T11859 And that's why I suggested a few comments ago to concentrate on fixing the re-indexing bug first. But it turned out to be not that easy. Together with the other performance issues and especially the tight coupling of mmap, access patterns, and available memory, I think it's worth rethinking if LMDB is still the right tool: mmap introduces a lot of problems and there's no easy way around it. There's to many things to think of to optimize access patterns then. It's unlikely to be done anytime when looking at the problems exposed by the database scheme already. LMDB seems to be designed around the idea to be the only user of system RAM, or at least only use a very smallish part of it (which may not be that small if you have huge amounts of RAM). That's unlikely to be the situation on systems where baloo is used. Bad design choices have already been made and been meshed deeply into the database scheme, which makes it difficult to migrate existing installations. BTW: Following up on your comment #2 was totally unintentional but actually I followed up and explained why that happens. ;-) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #33 from Kai Krakow --- Also, LMDB is totally the wrong tool when using 32-bit systems because your index cannot grow beyond a certain size before crashing baloo. I'm not sure if 32-bit systems are still a thing - but if they are, the decision for LMDB was clearly wrong. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #36 from Kai Krakow --- Oh, nice... Sometimes it helps to talk about a few things. I could think of the following solution: Add another UUID->CounterID mapping table to the database, that is easy to achieve. Everytime we encounter a new UUID, we increase the CounterID one above the maximum value in the DB and use that as a file system identifier. We can now bit-reverse the CounterID so that the least-significant bits switch position with the highest. The result will be XOR'ed with the 64-bit inode number. Et voila: There's a DocID. What do you think? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #38 from Kai Krakow --- (In reply to Martin Steigerwald from comment #35) > I like the idea to use one DB per filesystem. This way you can save the > complete filesystem UUID and/or other identifying information *once* and use > the full 64 bit for the inode number thing. Such things are always difficult (the same for your hidden ID file in the root of an FS): It requires permissions you may not have, thus you may decide to use the most top-level directory you have write permissions to. And at that point I'd define that the storage path is undefined. Other solution: Name the index files by UUID and store it at a defined location. We'll have other problems now: Do you really want multiple multi-GB mmaps LMDB files mapped at once in RAM? With even more chaotic random access patterns (and their potential to push your precious cache out of memory)? Also, multi-file databases are hard to sync with each other: At some point we may need to ensure integrity between all the files. This won't end well. I'm all in for a single-DB approach. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #40 from Kai Krakow --- Further research confirms: btrfs has unstable device ids because it exposes subvolumes as virtual block devices without their own device node in /dev. Thus, device id numbers are allocated dynamically at runtime from the kernel, the same happens for NFS and FUSE file systems. The latter usually even have unstable inode numbers. So currently, baloo is actually only safe to use on ext2/3/4 and xfs as the most prominent examples. On many other filesystems it will reindex files, and will even be unable to return proper results because reverse mapping of DocIds to filesystem paths is unreliable. This problem is deeply baked into the design of Baloo. My idea of merging device id and ino into one 64-bit integer wouldn't needing much modification to the existing code/storage format in theory. But apparently this would make using the reverse mapping impossible because the functions couldn't extract the device id from the docid to convert it back to a mount path. Additionally, btrfs shares the UUID between all subvolumes so using it would make duplicate inode numbers which would confuse baloo. Btrfs has UUID_SUB instead. After all, it seems we'd need a specialized GUID generator per filesystem type. Since GUID formats may differ widely, I'd suggest to create a registry table inside the database, much similar to my counted ID idea outlined above. Each new GUID would be simply registered in the table with a monotonically increasing number which can be used as the device ID for DocId. Still, we'd need to expand the DocId but temporarily it would do. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 412005] New: Konsole crashes when trying to paste (long texts) from clipboard
https://bugs.kde.org/show_bug.cgi?id=412005 Bug ID: 412005 Summary: Konsole crashes when trying to paste (long texts) from clipboard Product: konsole Version: 19.08.1 Platform: Gentoo Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: k...@kaishome.de Target Milestone: --- Application: konsole (19.08.1) Qt Version: 5.12.3 Frameworks Version: 5.61.0 Operating System: Linux 5.2.14-gentoo x86_64 Distribution: "Gentoo Base System release 2.6" -- Information about the crash: - What I was doing when the application crashed: I opened a konsole window, started vim, and then tried to insert around 20k text chars from clipboard using "Shift+Ins". Konsole crashed. This could be reproduced multiple times. The crash can be reproduced every time. -- Backtrace: Application: Konsole (konsole), signal: Segmentation fault [KCrash Handler] #7 0x003ef4e01170 in () #8 0x7fe593daa56a in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffb9f9ed68, env=env@entry=0x7fffb9f9ed78) at dl-init.c:72 #9 0x7fe593daa666 in call_init (env=0x7fffb9f9ed78, argv=0x7fffb9f9ed68, argc=1, l=) at dl-init.c:30 #10 0x7fe593daa666 in _dl_init (main_map=main_map@entry=0x7fe5640297c0, argc=1, argv=0x7fffb9f9ed68, env=0x7fffb9f9ed78) at dl-init.c:119 #11 0x7fe593dae573 in dl_open_worker (a=) at dl-open.c:506 #12 0x7fe593c4efc6 in _dl_catch_exception () at /usr/lib64/libc.so.6 #13 0x7fe593dade26 in _dl_open (file=, mode=-2147483646, caller_dlopen=0x7fe57d8bc970 , nsid=-2, argc=1, argv=, env=0x7fffb9f9ed78) at dl-open.c:588 #14 0x7fe59092729a in () at /usr/lib64/libdl.so.2 #15 0x7fe593c4efc6 in _dl_catch_exception () at /usr/lib64/libc.so.6 #16 0x7fe593c4f068 in _dl_catch_error () at /usr/lib64/libc.so.6 #17 0x7fe590927b1d in () at /usr/lib64/libdl.so.2 #18 0x7fe59092734d in dlopen () at /usr/lib64/libdl.so.2 #19 0x7fe57d8bc970 in module_Load (p_this=p_this@entry=0x7fe564024e40, path=0x561c236157b0 "/usr/lib64/vlc/plugins/codec/libfluidsynth_plugin.so", p_handle=p_handle@entry=0x7fe578dfd730, lazy=lazy@entry=false) at posix/plugin.c:60 #20 0x7fe57d85273c in module_Map (obj=obj@entry=0x7fe564024e40, plugin=0x561c23587ad0) at modules/bank.c:511 #21 0x7fe57d85149b in module_load (obj=obj@entry=0x7fe564024e40, init=init@entry=0x7fe57d8513f0 , args=args@entry=0x7fe578dfd828, m=, m=) at modules/modules.c:175 #22 0x7fe57d851907 in vlc_module_load (obj=obj@entry=0x7fe564024e40, capability=0x7fe57d8deb60 "audio decoder", name=0x7fe57d8cae11 "", name@entry=0x7fe57d8ce574 "$codec", strict=strict@entry=false, probe=probe@entry=0x7fe57d8513f0 ) at modules/modules.c:279 #23 0x7fe57d851ca4 in module_need (obj=obj@entry=0x7fe564024e40, cap=, name=name@entry=0x7fe57d8ce574 "$codec", strict=strict@entry=false) at modules/modules.c:371 #24 0x7fe57d868d68 in LoadDecoder (p_dec=p_dec@entry=0x7fe564024e40, b_packetizer=b_packetizer@entry=false, p_fmt=p_fmt@entry=0x7fe564024888) at input/decoder.c:179 #25 0x7fe57d869931 in CreateDecoder (p_sout=0x0, p_resource=, fmt=0x7fe564024888, p_input=0x561c23e3bf80, p_parent=0x561c23e3bf80) at input/decoder.c:1752 #26 0x7fe57d869931 in decoder_New (p_parent=p_parent@entry=0x561c23e3bf80, p_input=p_input@entry=0x561c23e3bf80, fmt=fmt@entry=0x7fe564024888, p_clock=, p_resource=, p_sout=0x0) at input/decoder.c:1913 #27 0x7fe57d86c0e8 in input_DecoderNew (p_input=p_input@entry=0x561c23e3bf80, fmt=fmt@entry=0x7fe564024888, p_clock=, p_sout=) at input/input_internal.h:183 #28 0x7fe57d86f081 in EsCreateDecoder (out=0x561c23447630, p_es=0x7fe564024870) at input/input_internal.h:183 #29 0x7fe57d86f225 in EsSelect (out=out@entry=0x561c23447630, es=es@entry=0x7fe564024870) at input/es_out.c:1778 #30 0x7fe57d870404 in EsOutSelect (out=out@entry=0x561c23447630, es=es@entry=0x7fe564024870, b_force=b_force@entry=false) at input/es_out.c:1990 #31 0x7fe57d871bbb in EsOutAddSlave (out=0x561c23447630, fmt=, p_master=0x0) at input/es_out.c:1649 #32 0x7fe57d877650 in es_out_Add (fmt=, out=) at ../include/vlc_es_out.h:125 #33 0x7fe57d877650 in CmdExecuteAdd (p_cmd=0x7fe578dfdb60, p_out=) at input/es_out_timeshift.c:1326 #34 0x7fe57d877650 in Add (p_out=, p_fmt=0x7fe56400a468) at input/es_out_timeshift.c:452 #35 0x7fe578cb100b in es_out_Add (fmt=0x7fe56400a468, out=) at ../include/vlc_es_out.h:125 #36 0x7fe578cb100b in Ogg_CreateES (p_demux=p_demux@entry=0x7fe5640012d0) at demux/ogg.c:2198 #37 0x7fe578cb5e62 in Demux (p_demux=0x7fe5640012d0) at demux/ogg.c:351 #38 0x7fe57d87d157 in demux_Demux (p_demux=0x7fe5640012d0) at ../include/vlc_demux.h:354 #39 0x7fe57d87d157 in MainLoopDemux (pb_changed=, p_input=0x561c23e3bf80) at input/input.c:577 #40 0x7fe57d87
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #7 from Kai Krakow --- Created attachment 122918 --> https://bugs.kde.org/attachment.cgi?id=122918&action=edit Reduce stack pressure This patch reduces pressure on the used stack size by looping instead of recursively calling itself when skipping files to index. This can add up a lot when skipping many files/directories in succession. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #8 from Kai Krakow --- Created attachment 122919 --> https://bugs.kde.org/attachment.cgi?id=122919&action=edit Experimental: Reduce mmap by one magnitude This patch reduces the memory map size for LMDB by one order of magnitude (16 instead of 256 GB). After applying the patch, I purged the DB and restarted baloo. It churns along nicely now, I/O is down to less than 10 MB/s instead of 50-100 MB/s constantly before. Also, running action that obviously do a bunch of memory allocations in Plasma (like opening the app drawer) now run much smoother again (instantly instead of a noticeable but subjective delay). The whole system feels much smoother again. I'm guessing that a lot of ongoing dirty-page writebacks, page faults and VMM handling has a lot of drawbacks and introduces a lot of TLB flushes because mappings into the process are constantly updated. It also seems to introduce a lot of I/O overhead. I'm not sure why that is but it seems this big mmap has indeed drawbacks. A lot of random accesses into the mmap may cause unintentional read-ahead, unpredictable IO patterns and may dominate the cache which is what I believe causes the excessive I/O behavior. This patch (together with the previous patch) makes my system run much nicer again. I can actually use krunner again without causing a lot of additional IO and lags. My system has 32 GB of RAM. Looking at all this, I wonder if LMDB is really the right tool. It is tempting to use it, but from the project documentation it seems to be intended as a read-mostly database. This is clearly not what baloo does with it, especially during re-indexing/updating or first indexing. The mmap size seems to be tightly bound to the maximum DB size which, looking at my above test results, limits the scaling of baloo a lot. It should probably not be too difficult to swap LMDB with another key/value database better fitting the usage pattern (bursts of lots of write transactions with only occasional read transactions when a user actually searches for something). LMDB (as the DBE backing the OpenLDAP project) seems to be designed for exactly the opposite usage pattern. Are there any more thoughts of it? Any idea which key/value DBE could fit better? What about multi-threading? Current code seems to run with only 1 thread in parallel only anyways despite using the thread pool classes of Qt. I'd volunteer to invest some spare time into swapping out LMDB for something different. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #9 from Kai Krakow --- Here's more evidence of why LMDB may be a particularly bad choice for the workload applied by baloo: It is btree organized, and writing and maintaining btrees will result in a lot of random I/O. At some point in time, when the DB has become big enough or scrambled enough due to constant updates, this will backfire badly resulting in very bad I/O patterns. https://blog.dgraph.io/post/badger-lmdb-boltdb/ Baloo should migrate to a key/value store that is much better at writing data and maintaining its internals. Read performance of the database should probably not be the primary concern but performance of long-term writing and updating: It should maintain good read and write performance. According to the article, LMDB doesn't (except you give it the full 256GB RAM and lock it into memory). Researching a little further, we can find a quite different picture: https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database It says that LMDB has exceptional write performance and maintains good performance altogether. Maybe this would need some benchmarks but it probably holds true only when the DB fully fits into memory all the time. And looking at the design description in that article we can easily see the downsides: The database can always only increase in size, even more when writing concurrently (there's no locking, so any time during concurrent access patterns it will append to the database). It also never re-organizes its internal structure, it just reuses memory blocks allocated from a free blocks tree without taking HDD access patterns into account. And, LMBDs design pays back best only with big values. I don't think this is what baloo stores. The article further says that LMDB can (on hypothetical file systems) fail on Linux when not using fsync(). Was fsync() added to LMDB for such a hypothetical case? This would be fatal to system performance. LMDB seems to be baked into a lot of KV databases due to it's seemingly good performance. So actually, this would need a lot more insight to decide whether LMDB is suitable for baloo (maybe it is but it isn't used optimally). Someone with more real-world experience of KV databases and associated usage patterns may comment on this. Currently, limiting the mmap size helps a lot here. And as mentioned by Martin, there's clearly a bug somewhere resulting in massive write work-loads and exceptional growth of the database. Maybe it's just a really bad access pattern by coincidence that results in exceptional bad behavior of LMDB. I was very happy with baloo performance for a long time until it suddenly broke some day. I'm not even sure that's baloo's fault: Judging from the commit subjects the code hasn't undergone any substantial changes since a long time, only small fixes and tweaks. There's commit b0890aca71aa4f0fdabe65ee7b7fbd0bc844d8b8 after KF 5.27.0 which bumped maximum index size from 5 GB to 256 GB. @Martin May this be around the time (end of 2016) when it broke for you? Your "balooctl indexSize" example seems to suggest there's a big rollover of copy-on-write operations leaving unused memory blocks behind (maybe to small to be effectively reused) and thus blowing up the DB file size. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #10 from Kai Krakow --- Created attachment 122925 --> https://bugs.kde.org/attachment.cgi?id=122925&action=edit Prepare simpler coding of environment flags This simply prepares the following patches and introduces no functional change. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #11 from Kai Krakow --- Created attachment 122926 --> https://bugs.kde.org/attachment.cgi?id=122926&action=edit Disable read-ahead of mmap access We should not read-ahead when accessing the database because it may introduce thrashing during low-mem situation because read-aheads would start dominating the cache. This also takes some pressure away from the file-system. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #12 from Kai Krakow --- Created attachment 122927 --> https://bugs.kde.org/attachment.cgi?id=122927&action=edit Don't fsync the file-system Let's not stress the system with fsync() after each DB transaction. This database can be easily rebuild in case it crashes. This patch removes latency spikes and input lag from the desktop environment while the indexer is running. It also seems to increase general indexing throughput while lowering the performance impact. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #13 from Kai Krakow --- I've added some patches to my experimental patchset after crunching through some of the documentation and articles available. The system responsiveness has improved a lot. Can anyone confirm that these patches help? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #14 from Kai Krakow --- Meanwhile, my patched indexer started content indexing phase. I also added back all the expensive directories I excluded previously. It's currently indexing with a mixed R/W workload of up to 200 MB/s (most time 50-100 MB/s) without much of an impact on desktop performance. Looks good so far. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #17 from Kai Krakow --- (In reply to Martin Steigerwald from comment #15) > Kai, thank you very much for your work on this! About an alternative to > LMDB… I am not sure at the moment. Will think about it. Currently with my patches it seems mostly fine with LMDB. The next days of usage will draw a better picture. I think baloo needs to handle LMDB just a little bit more optimized, i.e. does it use batched writes? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #18 from Kai Krakow --- (In reply to Martin Steigerwald from comment #16) > I bet I can just compile baloo via kdesrc. Does it have many dependencies on > KF libraries? I do not like to break my system at this point in time and it > has been a long time I last used kdesrc. I have no idea. I'm on Gentoo and just did "git format-patch origin/master", then symlinked my baloo Git src to /etc/portage/patches/kde-frameworks/baloo. So at least in Gentoo, that's a single package. Here's the deps from Gentoo: DEPEND=" $(add_frameworks_dep kconfig) $(add_frameworks_dep kcoreaddons) $(add_frameworks_dep kcrash) $(add_frameworks_dep kdbusaddons) $(add_frameworks_dep kfilemetadata) $(add_frameworks_dep ki18n) $(add_frameworks_dep kidletime) $(add_frameworks_dep kio) $(add_frameworks_dep solid) $(add_qt_dep qtdbus) $(add_qt_dep qtdeclarative) $(add_qt_dep qtgui) $(add_qt_dep qtwidgets) >=dev-db/lmdb-0.9.17 " I could attach my binary package if you want to try (it's basically a tar.gz, you could extract just the binaries and libs). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 356357] Continous index flushing with fdatasync degrades interactive performance
https://bugs.kde.org/show_bug.cgi?id=356357 Kai Krakow changed: What|Removed |Added CC||k...@kaishome.de --- Comment #14 from Kai Krakow --- I've added some patches before finding this bug. My findings are that disabling read-ahead on the database somewhat helps in low-mem situation but the biggest problem is fsync: That call will actually sync the whole filesystem and not just the database file, and doing that constantly is toxic to performance. It's as simple as that. Here's the link: https://bugs.kde.org/show_bug.cgi?id=404057 and https://github.com/kakra/baloo/commits/fixes/bko-404057. Some of these patches may not be needed at all, some optimize for corner cases. But we should really turn off fsync as the very least. If you don't want to disable fsync, then LMDB is probably the wrong tool to do the job. You'd then need some append-only database with garbage collection (LMDB is already acting a lot like this). I'm pretty sure LMDB is actually a bad choice for baloo, if, and only if, you expect it to be the only software needing to do IO. But after some research, I think LMDB is not the wrong tool, thus we need to adjust how Baloo uses it. The devs of LMDB say that it is safe to use without fsync on any current Linux filesystem (it can loose transactions but it won't corrupt). It is not safe to use on some hypothetical filesystems (it could corrupt). Can we please at least let the user decide and allow him to shoot his own foot? Maybe a config option or env variable? Baloo already has some sort of recovery: If it fails to open the database it will simply purge and recreate it. Maybe it could detect corruptions during use somehow and act similar? I'm not sure if LMDB function could return errors or simply cause crashes. In the first case, it should be easy. I also like the time-based instead of count-based approach much more: Linux already flushes data after no more than 30s, why not just use the same amount? Regarding fsync: I'm not sure if LMDB uses fsync or fdatasync, or if this is even a choice. The developers say in their documentation it's fsync, the strace by Riku says fdatasync. Whatever is used: It's a problem: You cannot expect users to use the software if it totally destroys their user experience. Baloo should be designed around the idea that corruption can occur and luckily it's easy to recover from it: Just rebuild the database. So the proposed solution is really about: How do we properly detect database corruption? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) and writes a *ton* of data while indexing
https://bugs.kde.org/show_bug.cgi?id=404057 --- Comment #19 from Kai Krakow --- After testing this a few days, with my patches it works flawlessly: No performance impact, krunner finds result immediately without thrashing the HDD, etc. That is, until you reboot: While with the patches it has no longer any perceived negative impact on desktop responsiveness, I see that Baloo still re-indexes all files. Steps to reproduce: 1. Start baloo for the first time (aka "remove your index") 2. Let it complete a full indexing cycle 3. Observe "balooctl indexSize" to see that there's no file left to index 4. Also observe that it has data in "ContentIndexingDB" 5. Reboot 6. Observe "balooctl indexSize" to see that "ContentIndexingDB" changed back to 0 bytes 7. Observe "balooctl status" and wait until it finished checking for missing files 8. Observe both commands to see how baloo now refills the ContentIndexingDB and adds all your files to the index again, resulting in double the amount of files after finishing the second run 9. From now on, on every reboot, the index only grows, constantly forgetting the ContentIndexDB and re-adding all files. This behavior is with and without my patches. @Martin Is this what you've seen, too? -- You are receiving this mail because: You are watching all bug changes.
