[Discover] [Bug 474944] New: High CPU usage when closing Discover after installing Firefox
https://bugs.kde.org/show_bug.cgi?id=474944 Bug ID: 474944 Summary: High CPU usage when closing Discover after installing Firefox Classification: Applications Product: Discover Version: 5.27.8 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Flatpak Backend Assignee: plasma-b...@kde.org Reporter: be...@igalia.com CC: aleix...@kde.org, jgrul...@redhat.com, trav...@redhat.com Target Milestone: --- Created attachment 161914 --> https://bugs.kde.org/attachment.cgi?id=161914=edit Stack trace SUMMARY I noticed that when you close Discover after installing Firefox the "plasma-discover" process keeps running using a lot of CPU for a minute or two. This does not happen with all apps, but it can be reproduced with Firefox (and also with other popular apps like VLC and Gimp). STEPS TO REPRODUCE 1. Open Discover 2. Search for Firefox (Flatpak) and open the package page (the one that shows the screenshots, version, size, license, ...) 3. Press "Install" on the top right corner 4. Wait for the installation to finish. 5. Close Discover 6. Open a terminal and look for running processes (with 'top' or similar) OBSERVED RESULT The "plasma-discover" process keeps running for a minute or two using a lot of CPU EXPECTED RESULT The "plasma-discover" process dies shortly after closing the Discover window. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma version: 5.27.8 KDE Frameworks version: 5.110.0 Qt version: 5.5.10 Discover: 5.27.8 ADDITIONAL INFORMATION I'm attaching a stack trace of the running plasma-discover process after the main window is closed. >From the high number of QQuickItemPrivate::derefWindow() calls it seems that a large number of widgets are being destroyed. I haven't debugged it but Firefox in particular has almost 2000 reviews on Flathub, and I have a have a hunch that this might be the cause of the problem (is Discover preloading them or something?). On a second test, installing Firefox directly from the Discover search results (i.e. without opening the page) does not seem to cause this problem. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 474231] New: "Too many open files" when trying to update a large number of refs
https://bugs.kde.org/show_bug.cgi?id=474231 Bug ID: 474231 Summary: "Too many open files" when trying to update a large number of refs Classification: Applications Product: Discover Version: 5.27.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Flatpak Backend Assignee: plasma-b...@kde.org Reporter: be...@igalia.com CC: aleix...@kde.org, jgrul...@redhat.com, trav...@redhat.com Target Milestone: --- STEPS TO REPRODUCE 1. Have a Flatpak installation with ~50 pending updates 2. Open Discover, select "Update" and click "Update all" OBSERVED RESULT The application crashes. The exact stack trace and journal messages are different each time, but they are all variations of "Too many open files": plasma-discover[3235]: Creating pipes for GWakeup: Too many open files plasma-discover[4090]: Error spawning revokefs-fuse: Too many open files plasma-discover[3518]: Cannot create repo on revokefs mountpoint /var/tmp/flatpak-cache-T1LSA2/org.gnome.Platform.Locale-SQUKA2: opening repo: While checking parent repository '/var/lib/flatpak/repo': opening repo: opendir(tmp): Too many open files There is also a large number of /usr/lib/revokefs-fuse processes running. EXPECTED RESULT All refs are updated correctly. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.19.5 ADDITIONAL INFORMATION Having a look at the discover Flatpak backend I see that FlatpakBackend::installApplication() is called in a loop for every application that needs to be updated: https://invent.kde.org/plasma/discover/-/blob/v5.27.5/libdiscover/resources/StandardBackendUpdater.cpp?ref_type=tags#L65 Each one of these creates a new FlatpakJobTransaction, each with its own FlatpakTransactionThread which in turn has its own FlatpakTransaction object: https://invent.kde.org/plasma/discover/-/blob/v5.27.5/libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp?ref_type=tags#L101 In other words, instead of creating one FlatpakTransaction and putting all refs in it it creates one transaction per ref and (as far as I can see) runs them all in parallel. I haven't confirmed it yet but I suspect that the problem is related to this. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] Unmounting certain SD cards can triggers an immediate remount when using "automount on attach" setting
https://bugs.kde.org/show_bug.cgi?id=467751 --- Comment #11 from Alberto Garcia --- There's one more thing to take into account with the "5 seconds since plugged" heuristic: the case when the volume was present at coldplug (i.e. it was already there when the session started). Related links for the GNOME implementation: https://gitlab.gnome.org/GNOME/gvfs/-/commit/e30a67f3215d829e95ee7e358c67af7d67635fe8 https://bugzilla.redhat.com/show_bug.cgi?id=813069 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] Unmounting certain SD cards can triggers an immediate remount when using "automount on attach" setting
https://bugs.kde.org/show_bug.cgi?id=467751 --- Comment #10 from Alberto Garcia --- (In reply to Stefan Brüns from comment #9) > According to the strace output, the drive supports none of the four > attempted methods of eject, i.e. the ioctl's 'CDROM_LOCKDOOR', 'SG_IO(...)', > 'FDEJECT' and 'MTIOCTOP'. FWIW the same happens with QEMU's virtual SD card reader (the strace output I attached earlier is from actual hardware). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] Unmounting certain SD cards can triggers an immediate remount when using "automount on attach" setting
https://bugs.kde.org/show_bug.cgi?id=467751 --- Comment #8 from Alberto Garcia --- Created attachment 157742 --> https://bugs.kde.org/attachment.cgi?id=157742=edit strace output The strace output is attached. Here's the output of the eject and monitor commands: # /usr/bin/eject /dev/mmcblk0; echo $? eject: unable to eject 1 # udisksctl monitor Monitoring the udisks daemon. Press Ctrl+C to exit. 15:43:49.633: The udisks-daemon is running (name-owner :1.29). 15:43:50.504: Removed /org/freedesktop/UDisks2/block_devices/mmcblk0p1 15:43:50.538: /org/freedesktop/UDisks2/block_devices/mmcblk0: org.freedesktop.UDisks2.PartitionTable: Properties Changed Partitions: 15:43:50.629: Added /org/freedesktop/UDisks2/block_devices/mmcblk0p1 org.freedesktop.UDisks2.Block: Configuration: [] CryptoBackingDevice:'/' Device: /dev/mmcblk0p1 DeviceNumber: 45825 Drive: '/org/freedesktop/UDisks2/drives/SL16G_0x8c9ed258' HintAuto: true HintIconName: HintIgnore: false HintName: HintPartitionable: true HintSymbolicIconName: HintSystem: false Id: by-uuid-9019398f-1e38-4f69-bca4-6feb56d98ed7 IdLabel:SD_CARD IdType: ext4 IdUUID: 9019398f-1e38-4f69-bca4-6feb56d98ed7 IdUsage:filesystem IdVersion: 1.0 MDRaid: '/' MDRaidMember: '/' PreferredDevice:/dev/mmcblk0p1 ReadOnly: false Size: 15929966592 Symlinks: /dev/disk/by-id/mmc-SL16G_0x8c9ed258-part1 /dev/disk/by-label/SD_CARD /dev/disk/by-partlabel/primary /dev/disk/by-partuuid/679ecb89-c2df-4e55-ac6a-e8be61e2709d /dev/disk/by-uuid/9019398f-1e38-4f69-bca4-6feb56d98ed7 UserspaceMountOptions: org.freedesktop.UDisks2.Filesystem: MountPoints: Size: 15929966592 org.freedesktop.UDisks2.Partition: Flags: 0 IsContained:false IsContainer:false Name: primary Number: 1 Offset: 1048576 Size: 15929966592 Table: '/org/freedesktop/UDisks2/block_devices/mmcblk0' Type: 0fc63daf-8483-4772-8e79-3d69d8477de4 UUID: 679ecb89-c2df-4e55-ac6a-e8be61e2709d 15:43:50.629: /org/freedesktop/UDisks2/block_devices/mmcblk0: org.freedesktop.UDisks2.PartitionTable: Properties Changed Partitions: /org/freedesktop/UDisks2/block_devices/mmcblk0p1 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] Unmounting certain SD cards can triggers an immediate remount when using "automount on attach" setting
https://bugs.kde.org/show_bug.cgi?id=467751 --- Comment #3 from Alberto Garcia --- In case you want to give it a try with QEMU, here's a very simple test case: 1) Boot a VM with a virtual SD card reader, like this: -device sdhci-pci -device sd-card,drive=mmc0 -drive if=none,file=card.qcow2,id=mmc0 2) Add a partition to the SD card, no need to format it (you can use GPT or DOS/MBR, it doesn't matter). 3) Run `udevadm monitor` and in a different terminal run `eject /dev/mmcblk0` This is enough to see the udev events I mentioned earlier. The check that you describe seems fine (assuming that timeout is not too small). Thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 446395] Unmounting an SD card in the internal reader using the device notified leads to it being mounted again
https://bugs.kde.org/show_bug.cgi?id=446395 Alberto Garcia changed: What|Removed |Added Resolution|FIXED |DUPLICATE CC||be...@igalia.com --- Comment #2 from Alberto Garcia --- I just collected all the details about how to reproduce this problem and I had overlooked that you had reported this. Marking as duplicate. See the linked bug for all the details. *** This bug has been marked as a duplicate of bug 467751 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] Unmounting an SD card triggers a remount
https://bugs.kde.org/show_bug.cgi?id=467751 Alberto Garcia changed: What|Removed |Added CC||m...@ramendik.ru --- Comment #1 from Alberto Garcia --- *** Bug 446395 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 467751] New: Unmounting an SD card triggers a remount
https://bugs.kde.org/show_bug.cgi?id=467751
Bug ID: 467751
Summary: Unmounting an SD card triggers a remount
Classification: Frameworks and Libraries
Product: frameworks-solid
Version: 5.103.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: be...@igalia.com
CC: kdelibs-b...@kde.org, lu...@kde.org
Target Milestone: ---
SUMMARY
Unmounting an SD card results in it being re-mounted again if "automount on
attach is enabled".
STEPS TO REPRODUCE
1. Enable "Automount all known devices on attach" on the desktop settings.
2. Insert an SD card in the reader (can be reproduced on a VM). The volume
should be mounted automatically.
3. Click on "Safely remove" to unmount the volume.
OBSERVED RESULT
The volume is re-mounted again immediately.
EXPECTED RESULT
The volume remains unmounted.
SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.27.2
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
ADDITIONAL INFORMATION
Hi,
I'm unsure about whether this is an actual bug in KDE, UDisks, or not a bug at
all, so let me explain the situation.
SD card readers have the "MediaRemovable" flag set in UDisks:
https://github.com/storaged-project/udisks/blob/2.9.x-branch/src/udiskslinuxdrive.c#L368
This, according to the UDisks documentation, seems to only mean that "the media
can be removed from the drive".
However, Solid uses that information to decide whether to _eject_ the volume
when the user tries to "Safely remove" the volume from the desktop. The
"Ejectable" flag from UDisks was previously used for this purpose but it was
discarded because it was considered broken (bug #402096, commit
https://github.com/KDE/solid/commit/6d260195cf75604d835235d2a1b02166ee8b514a).
The UDisks Eject command runs /usr/bin/eject under the hood, but this won't
actually eject the card from the reader, so it fails (I'm using a VM in this
example but the same happens with real hardware):
$ busctl call org.freedesktop.UDisks2
/org/freedesktop/UDisks2/drives/QEMU__0xdeadbeef org.freedesktop.UDisks2.Drive
Eject 'a{sv}' 0
Call failed: Error ejecting /dev/mmcblk0: Command-line `eject
'/dev/mmcblk0'' exited with non-zero exit status 1: eject: unable to eject
This results in the following udev events:
UDEV [9144.057110] remove
/devices/pci:00/:00:04.0/mmc_host/mmc0/mmc0:4567/block/mmcblk0/mmcblk0p1
(block)
UDEV [9144.105960] change
/devices/pci:00/:00:04.0/mmc_host/mmc0/mmc0:4567/block/mmcblk0 (block)
UDEV [9144.193215] add
/devices/pci:00/:00:04.0/mmc_host/mmc0/mmc0:4567/block/mmcblk0/mmcblk0p1
(block)
Because of these remove+add events, if "Automount all known devices on attach"
is set under the removable devices settings and you try to safely remove an SD
card then the volume is immediately re-mounted again.
I also noticed that this does not happen in GNOME and this is due to a
workaround there: if a volume appears much later than the drive (as in this
case) then it is not mounted automatically:
https://gitlab.gnome.org/GNOME/gvfs/-/commit/b4800b987b4a8423a52306c9aef35b3777464cc5
So while doing something like this would be a possibility, is it maybe possible
to find a way to know whether the media in a certain drive is actually
ejectable, and not simply removable? Otherwise it seems that Solid should not
try to use eject based only on the "MediaRemovable" flag.
Opinions?
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 455702] Icon missing after installing an application from Flatpak
https://bugs.kde.org/show_bug.cgi?id=455702 --- Comment #4 from Alberto Garcia --- Hmmm... I tried again starting with a fresh session and this time the SuperTux icon didn't appear. Then I repeated the same process with Telegram and this one still shows the correct icon. Both apps installed from Discover. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455702] Icon missing after installing an application from Flatpak
https://bugs.kde.org/show_bug.cgi?id=455702 --- Comment #3 from Alberto Garcia --- I forgot: it also does NOT happen with SuperTux -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455702] Icon missing after installing an application from Flatpak
https://bugs.kde.org/show_bug.cgi?id=455702 Alberto Garcia changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Alberto Garcia --- (In reply to David Edmundson from comment #1) > Can you confirm if it happens with all apps; such as installing supertux > from discover? > Firefox has some quirks due to it being on the panel, the path through > prefferredbrowser:// I tried a few more apps. The same problem happens with: - Spotify - ScummVM - Steam - Calibre It does NOT happen with: - Telegram -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455702] New: Icon missing after installing an application from Flatpak
https://bugs.kde.org/show_bug.cgi?id=455702 Bug ID: 455702 Summary: Icon missing after installing an application from Flatpak Product: plasmashell Version: 5.25.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Menu (Kicker) Assignee: plasma-b...@kde.org Reporter: be...@igalia.com Target Milestone: 1.0 SUMMARY After installing an app from Flatpak the launcher appears on the application menu and the panel. However instead of the proper icon from the app what you see is an "empty page" icon (I believe it's application-x-zerosize). The launcher itself works fine and Firefox opens as expected. Also, after restarting the desktop session the correct icon appears. Note: this only happens with apps installed from Flatpak. If you install Firefox from the distribution's package manager then the Firefox icon appears correctly right away without having to restart anything. STEPS TO REPRODUCE 1. Open a terminal and type 'flatpak install firefox' (choose the /stable branch) 2. Wait a few seconds, go to the application menu -> Internet and look at the Firefox launcher 3. Alternatively look at the Firefox launcher on the panel. OBSERVED RESULT Firefox is using the incorrect icon EXPECTED RESULT Firefox is using the well-known Firefox logo SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 -- You are receiving this mail because: You are watching all bug changes.
