| Summary: | Kasts sometimes crashes when pressing the Refresh all podcasts button while it's playing an audio | ||
|---|---|---|---|
| Product: | [Applications] kasts | Reporter: | Josep Febrer <jfebrer> |
| Component: | general | Assignee: | bart |
| Status: | ASSIGNED --- | ||
| Severity: | crash | Keywords: | drkonqi |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | https://crash-reports.kde.org/organizations/kde/issues/86782/events/c9800eea5d0d439ab672617c57242aa9/ | ||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Josep Febrer
2024-10-28 13:04:41 UTC
Created attachment 175306 [details]
New crash information added by DrKonqi
DrKonqi auto-attaching complete backtrace.
Due to missing symbols, I don't see anything in particular that would point to the crash in your case. Having said that, I've been getting a lot of these crashes myself. This only started happening very recently and seems to be correlated with "database is locked" errors. I have the impression that something in an underlying library has changed recently (perhaps in qt6?). I'm assuming that your crash is due to the same reason. The current code is updating the database from multiple threads simultaneously. The way it's implemented should be allowed and should be thread-safe, and this implementation worked for several years without any reports. So, I'm not sure what changed... I think I'll need to refactor the database update to be handled by one thread after all rss feeds have been parsed. I had made an internal ticket a long time ago to do this refactoring anyway, since it has a few additional advantages on long term. I guess this has now moved it up in priority. Git commit f2c6188c1acd042000b08acc95612b1f268aa37d by Bart De Vries. Committed on 19/02/2025 at 10:08. Pushed by bdevries into branch 'release/24.12'. Disable hstsstore (temporarily) Disable hstsstore temporarily because of a common malloc crash deep in qt6 somewhere. This is to be reenabled once the bug is solved upstream. M +3 -1 src/fetcher.cpp https://invent.kde.org/multimedia/kasts/-/commit/f2c6188c1acd042000b08acc95612b1f268aa37d I've been able to reproduce the issue. It seems to be caused somewhere deep inside qt6. It seems that there are several similar drkonqi crash reports in the crash reporting system, e.g. https://crash-reports.kde.org/organizations/kde/issues/131265?project=384 . All of these seem to be related to a call to isWritable() on the hstsstore. This then tries to create several file-like objects, and the crash seems to be happening in a new call on one of them. I've pushed an update to disable the hstsstore until this bug is solved upstream. This seems to be an effective workaround, since it avoids triggering the code that causes the issue. I'll leave this report open until the underlying bug is solved and the hstsstore can be enabled again. |