[frameworks-baloo] [Bug 380456] Suspected memory leak in baloo_file_extractor
https://bugs.kde.org/show_bug.cgi?id=380456 DDR <robertsdavid...@gmail.com> changed: What|Removed |Added CC||robertsdavid...@gmail.com --- Comment #1 from DDR <robertsdavid...@gmail.com> --- Created attachment 110170 --> https://bugs.kde.org/attachment.cgi?id=110170=edit Upon killing baloo_file_extractor, I suddenly have a lot more free memory. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 380456] Suspected memory leak in baloo_file_extractor
https://bugs.kde.org/show_bug.cgi?id=380456 --- Comment #2 from DDR <robertsdavid...@gmail.com> --- Comment on attachment 110170 --> https://bugs.kde.org/attachment.cgi?id=110170 Upon killing baloo_file_extractor, I suddenly have a lot more free memory. baloo_file_extractor always seems to use about 16gb of memory, allocated fairly quickly after I start my computer. Commands such as ` balooctl index * ` are unresponsive until I've killed the process. I'm running Ubuntu 17.10, which is up-to-date as today. (2018-01-27) I don't think the index is an issue, even if it was held entirely memory it wouldn't account for half the problem. $ balooctl indexSize Actual Size: 6.80 GiB Expected Size: 5.04 GiB When the memory usage is high (before the cliff in the attached image): $ balooctl status Baloo File Indexer is running ^C After I kill baloo_file_extractor (after the cliff in the attached image): $ balooctl status Baloo File Indexer is running Indexer state: Indexing file content Indexed 356513 / 374337 files Current size of index is 11.08 GiB Let me know if I can provide any more information. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 380456] Suspected memory leak in baloo_file_extractor
https://bugs.kde.org/show_bug.cgi?id=380456 --- Comment #5 from DDR <robertsdavid...@gmail.com> --- OK, so I have just discovered the magic of ls -la /proc/1234/fd, where 1234 is the pid of baloo_file_extractor. baloo_file_extractor was busy on a 1.5GiB text file, production-aria-tables.sql, and then got stuck on its backup. I added these files to the ignore list, in File Search — System Settings, and the indexer has gotten on with life and is indexing the last few files it needs to. Unfortunately, as the file is a database dump of mlpforums.com, I cannot share it for reproduction due to confidentiality issues. Perhaps a partial dump of the kde bugs database would suffice for that purpose. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 380456] Suspected memory leak in baloo_file_extractor
https://bugs.kde.org/show_bug.cgi?id=380456
--- Comment #6 from DDR <robertsdavid...@gmail.com> ---
> Please report memory usage when indexing is done. I'm really curious to see
> that.
About 1.1GiB, ~5% of the available system memory. Very reasonable.
> Did you kill it? Probably not. I've encountered this many times.
No, not as of the report. I did shortly after - it was that, or it killed me by
swapping anything useful to disk.
> Please clarify 'unresponsive': Did you have to Ctrl-C?
Yes. I think balooctl it was waiting for baloo_file_extractor to provide some
information, but the extractor never would. I think it was busy extracting. I
don't have a way to ctrl-c file extractor, but I think when I send the
equivalent signal it shuts down just fine. ("End Process" in system monitor.)
> With an index of that size searching might be a little slow. And your even
> half-way done :)
> Not sure, but I have the feeling baloo wasn't designed for this and you're
> overburdening it.
Searching is still lightning fast. It seems it was designed very well in that
regard.
I was definitely overburdening it. I feel it really should have known better
than to try to index a tremendous plain-text file, though. It is enthusiastic,
it bit off significantly more than it could chew. The actual search index for
the forum the database dump was from takes over a week to rebuild on the
server, I imagine the more generalised search tool would be absolutely doomed
in that endeavour. That, and a week of solid uptime is quite rare for me.
> I'm just trying to imagine what will happen when you enter 'const' in
> KRunner/Milou.
Would Dolphin's ctrl-f suffice? It's up to 1158 folders and 115308 files.
Somewhat amazingly, although the search results took a few minutes to populate,
Dolphin itself is still perfectly responsive and I can scroll through the files
just fine. Typing to select a file works both perfectly and instantly. Memory
use remaned unremarkably low throughout the whole process, and didn't really
change when I exited Dolphin.
All 374579 files have now finished indexing. The current size of the index is
11.08 GiB.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 421373] New: Emojis aren't rendered to the grid in the emoji picker, making it rather hard to pick them.
https://bugs.kde.org/show_bug.cgi?id=421373 Bug ID: 421373 Summary: Emojis aren't rendered to the grid in the emoji picker, making it rather hard to pick them. Product: plasmashell Version: 5.18.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Emoji picker Assignee: plasma-b...@kde.org Reporter: robertsdavid...@gmail.com Target Milestone: 1.0 Created attachment 128373 --> https://bugs.kde.org/attachment.cgi?id=128373=edit A screenshot of the emoji picker, scrolled down a bit, displaying some emojis off-grid and the selector and tofu on-grid. SUMMARY Emojis aren't rendered to the grid in the emoji picker, making it rather hard to pick them. STEPS TO REPRODUCE 1. Start emoji picker. OBSERVED RESULT Emojis are offset from the grid table they're in. Selector and tofu is not. EXPECTED RESULT Emojis are rendered to the same grid as everything else. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 20.04 LTS KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Perhaps my use of noto-color-emoji has something to do with this? Or the screen scaling factor of 1.6? I'm assuming Emoji Picker version is the same as KDE version, since I can't find a package or figure out how to bring up an about menu in the Emoji Picker. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 421373] Emojis aren't rendered to the grid in the emoji picker, making it rather hard to pick them.
https://bugs.kde.org/show_bug.cgi?id=421373 DDR changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #4 from DDR --- Fixed in 5.19. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 380456] Suspected memory leak in baloo_file_extractor
https://bugs.kde.org/show_bug.cgi?id=380456 --- Comment #15 from DDR --- I second this. It's a bit absurd to just run it with no resource limits, internally or externally. On Wed., Oct. 13, 2021, 11:04 p.m. Adam Fontenot, wrote: > https://bugs.kde.org/show_bug.cgi?id=380456 > > Adam Fontenot changed: > >What|Removed |Added > > > CC| > |adam.m.fontenot+kde@gmail.c >||om > > --- Comment #14 from Adam Fontenot --- > This is still a really common issue. I don't know that I've ever spoken to > someone who uses KDE + Baloo with the out of the box settings who hasn't > run > into it. I mean, just for a starting sample: > > > https://old.reddit.com/r/kde/comments/j77j16/can_we_please_have_kde_disable_baloo_by_default/ > > https://old.reddit.com/r/kde/comments/kzdoux/baloo_should_be_suspended_when_the_system_is_in/ > https://old.reddit.com/r/kde/comments/lgg0su/how_is_baloo_doing_these_days/ > https://old.reddit.com/r/kde/comments/o6w0ly/whats_wrong_with_baloo/ > > https://old.reddit.com/r/kde/comments/pc4wk1/baloo_file_extr_extreme_cpu_usage/ > > This is just the first five issues I could find with people talking about > this > *exact* problem, but the list goes on and on. The oldest complaint in that > list > is only a year old. > > More than a complaint, I have a proposal: it is completely unreasonable > for a > file indexer to ever make a user's system unusable. Any time it takes > baloo_file_extractor more than 30 seconds to pull the text out of a file, > or it > starts using more than 10% of the user's total RAM, it should be instantly > killed and the file blacklisted. Only the file name (not contents) should > be > available to search results. > > Moreover, some kind of heuristic is desperately needed to tell Baloo that a > file can't be usefully indexed. Baloo is happy to use a ton of memory and > hard > disk space to index files that are - for most purposes - random binary > data. > > Just as an example: I have a PDF that contains no meaningful text at all > (it's > a plot automatically generated from some technical data). It's only 20 MB. > Yet > baloo_file_extractor hung on this file for a *long* time, probably more > than > half an hour, with RAM use up over 1 GB. It continued using 100% of one CPU > core despite the fact that I was trying to run a full screen game at the > time. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 480179] KDE Connect Daemon crashes after update to Frameworks 5.114.0
https://bugs.kde.org/show_bug.cgi?id=480179 DDR changed: What|Removed |Added CC||robertsdavid...@gmail.com --- Comment #8 from DDR --- I'm seeing this myself, restarting after a recent update in the past two-three days here. -- You are receiving this mail because: You are watching all bug changes.
