| Summary: | Baloo is crashing at startup | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kfilemetadata | Reporter: | DaBler <dabler> |
| Component: | general | Assignee: | Pinak Ahuja <pinak.ahuja> |
| Status: | CONFIRMED --- | ||
| Severity: | crash | CC: | postix, public, stefan.bruens, tagwerk19 |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 5.68.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=477115 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
DaBler
2020-05-11 07:12:54 UTC
The extractor from KFileMetadata is crashing. 'balooctl failed' will tell which file causes the crash. (In reply to Stefan Brüns from comment #1) > The extractor from KFileMetadata is crashing. > > 'balooctl failed' will tell which file causes the crash. $ balooctl failed All Files were indexed successfully Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! From the backtrace, it looks like there is a text file larger than 2 GiB. Qt only supports up to 2 GiB. I suggest to add incremental loading to the plaintextextractor. HP ZBook 15 G3 with fresh install of kubuntu 20.04. This bug seems to be affecting me, after login to Plasma baloo_file_extractor crashes repeatedly. The crash notifications are more disturbing for the workflow than the crash itself. ~$ balooctl failed All Files were indexed successfully The Crash Reporting Assistant wants me to create a backtrace, but I do not understand how to do that. I can't find -dbg or -dbgsys packages for any of the libraries listed. The guide at https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Preparing_your_KDE_packages tells me to "Always install kdelibs5-dbgsym" but I can't find that either. Error message and packages listed are: "Missing debug information packages - The KDE Crash Handler The packages containing debug information for the following application and libraries are missing: /usr/bin/baloo_file_extractor /lib/x86_64-linux-gnu/libQt5Core.so.5 /lib/x86_64-linux-gnu/liblmdb.so.0 /lib/x86_64-linux-gnu/libQt5Widgets.so.5 /lib/x86_64-linux-gnu/libKF5BalooEngine.so.5" Since I only can provide the automatic backtrace information, the Crash Reporting Assistant does not let me continue, stating I've not provided enough information. (In reply to DaBler from comment #2) > (In reply to Stefan Brüns from comment #1) > > The extractor from KFileMetadata is crashing. > > > > 'balooctl failed' will tell which file causes the crash. > > $ balooctl failed > All Files were indexed successfully This is probably caused by DrKonqi messing up signal delivery. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/baloo/-/merge_requests/174 That explains a lot! Is the "... depends on the kernel /proc/sys/kernel/core_pattern setting ..." a distribution thing? I've never, as far as I remember, found files listed as failed. If this fixes repeat crashes because baloo wants and fails (and wants and fails...) to index a particular file, that's a *big* step.... On Tumbleweed, the pattern is set by installing the `systemd-coredump` package: $> grep core_pattern /usr/lib/sysctl.d/50-coredump.conf kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h (In reply to Christoph Feck from comment #4) > From the backtrace, it looks like there is a text file larger than 2 GiB. Qt > only supports up to 2 GiB. > > I suggest to add incremental loading to the plaintextextractor. I suggest to open a MR. (In reply to Christoph Feck from comment #4) > From the backtrace, it looks like there is a text file larger than 2 GiB. Qt only supports up to 2 GiB. Not sure what Baloo would do with a 2GB file... Thought there was a "rough limit" of 10 Mbyte, see https://bugs.kde.org/show_bug.cgi?id=410680#c7 Doesn't always seem to cut in, maybe does for some filetypes and not others. Cf Bug 447681 Git commit 819cb757b5742372cf017fba84955178c1f1a7d1 by Stefan Brüns. Committed on 14/11/2023 at 01:28. Pushed by bruns into branch 'master'. [ExtractorProcess] Handle signal mangling by DrKonqi DrKonqui catches the SIGSEGV or SIGILL from a misbehaving extractor, and then eventually quits the process. This may happen either by re-raising the signal, or just are regular `_exit(253)`. Which one is used depends on the kernel `/proc/sys/kernel/core_pattern` setting - if it uses a pipe, the signal will be reraised. The unexpected exit status was not handled before, and could cause a blocking indexer, as neither a `done()` or `failed()` signal would ever be emitted. This also causes the list of failed files to stay empty, i.e. `balooctl failed` would not return anything. M +1 -1 src/file/CMakeLists.txt M +12 -4 src/file/extractorprocess.cpp https://invent.kde.org/frameworks/baloo/-/commit/819cb757b5742372cf017fba84955178c1f1a7d1 Git commit fd24c90c1eaaaa465324baa81a622f8767b62eef by Stefan Brüns. Committed on 16/11/2023 at 04:18. Pushed by bruns into branch 'kf5'. [ExtractorProcess] Handle signal mangling by DrKonqi DrKonqui catches the SIGSEGV or SIGILL from a misbehaving extractor, and then eventually quits the process. This may happen either by re-raising the signal, or just are regular `_exit(253)`. Which one is used depends on the kernel `/proc/sys/kernel/core_pattern` setting - if it uses a pipe, the signal will be reraised. The unexpected exit status was not handled before, and could cause a blocking indexer, as neither a `done()` or `failed()` signal would ever be emitted. This also causes the list of failed files to stay empty, i.e. `balooctl failed` would not return anything. (cherry picked from commit 819cb757b5742372cf017fba84955178c1f1a7d1) M +1 -1 autotests/unit/file/CMakeLists.txt M +1 -1 src/file/CMakeLists.txt M +12 -4 src/file/extractorprocess.cpp https://invent.kde.org/frameworks/baloo/-/commit/fd24c90c1eaaaa465324baa81a622f8767b62eef (In reply to tagwerk19 from comment #11) > (In reply to Christoph Feck from comment #4) > > From the backtrace, it looks like there is a text file larger than 2 GiB. Qt only supports up to 2 GiB. > Not sure what Baloo would do with a 2GB file... > > Thought there was a "rough limit" of 10 Mbyte, see > https://bugs.kde.org/show_bug.cgi?id=410680#c7 > > Doesn't always seem to cut in, maybe does for some filetypes and not others. > Cf Bug 447681 The limit is currently only applied when the detected mimetype is a subtype of "text/", not when it is a specialized (inherited) type of e.g. text/plain. For example, "application/json" or "message/rfc822". For a more complete list: $> grep -E '<mime|sub-class' /usr/share/mime/packages/freedesktop.org.xml | grep -B1 -E 'sub-class.*text/' | grep -v 'mime-type.*text/' | sed -nE '/mime-type/ { N; s@.*="([^"]*).*\n.*"(.*)".*@\1 \t->\t\2 @ ; p} ' | tee /dev/stderr | wc -l That lists 64 types. You can find such files with e.g. $> baloosearch -t Text mimetype:application or mimetype:message |