Summary: | Corrupted KCrash files appear in home directory | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kcrash | Reporter: | ha51wl8j |
Component: | general | Assignee: | David Faure <faure> |
Status: | REOPENED --- | ||
Severity: | crash | CC: | gerrit.huebbers, kdelibs-bugs, nate, tagwerk19 |
Priority: | NOR | ||
Version: | 5.103.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
ha51wl8j
2023-03-09 09:53:41 UTC
*** This bug has been marked as a duplicate of bug 465801 *** My report wasn't intended to be a crash report for baloo. It was more about the corrupted files in my home directory which should not appear no matter how much baloo crashes. I just thought it could be useful to include the stack trace as well. (In reply to ha51wl8j from comment #2) > ... more about the corrupted files in my home directory which should not appear no matter > how much baloo crashes ... There might be a "distribution" component... I could replicate the crashes, with "left over" files in $HOME, on Arch. I remember I didn't encounter the issue on Neon Unstable, but I did get a notification on Fedora 37: Kcrash: Application '???zU' crashing... (application name varies...) Kcrash: Attempting to start >:EzU Warning: socket path is too long Kcrash failed to exec(), errno = 2 But I did not seem to get a corrupt coredump I tried Tumbleweed and got crashes, listed by coredumpctl, but no notifications or strange files. Best to consider these as recollections (based on scribbled notes) rather than hard, reproduceable, evidence. In all cases the upgrade to Frameworks 5.104 fixed the baloo_file_extractor crash. |