Summary: | Assert in lod counter | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Tiar <tamtamy.tymona> |
Component: | General | Assignee: | Dmitry Kazakov <dimula73> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | dimula73 |
Priority: | NOR | ||
Version: | git master (please specify the git hash!) | ||
Target Milestone: | --- | ||
Platform: | Mint (Ubuntu based) | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/4af3922863f461bfc3852a1d2c538fbb65050a49 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: | Crash log for all threads |
Description
Tiar
2021-03-20 02:03:43 UTC
Git commit 96d2a09d7eb20543051489d0d21651a4c49bf636 by Dmitry Kazakov. Committed on 21/05/2021 at 10:52. Pushed by dkazakov into branch 'master'. Fix a race condition when starting spontaneous jobs When starting any job we should always explicitly compare the status of the current level of detail. Just the fact that there is no merge/stroke jobs in the updater context is not enough. It happens because an update job transitions into an empty state in three stages. Firstly, it is marked as WAITING, then its lod ticket is removed from the updater context, and, finally, if it is not assigned with any nice task again, it switches into EMPTY state. Between the first and the second states there is a short fragile period when getJobsSnapshot() will return nothing, but currentLevelOfDetail() will still return LoD of the latest job. This state is "okay", we just need to restart queue processing in this case. M +5 -2 libs/image/kis_simple_update_queue.cpp https://invent.kde.org/graphics/krita/commit/96d2a09d7eb20543051489d0d21651a4c49bf636 Git commit 4af3922863f461bfc3852a1d2c538fbb65050a49 by Dmitry Kazakov. Committed on 01/06/2021 at 12:07. Pushed by dkazakov into branch 'krita/4.3'. Fix a race condition when starting spontaneous jobs When starting any job we should always explicitly compare the status of the current level of detail. Just the fact that there is no merge/stroke jobs in the updater context is not enough. It happens because an update job transitions into an empty state in three stages. Firstly, it is marked as WAITING, then its lod ticket is removed from the updater context, and, finally, if it is not assigned with any nice task again, it switches into EMPTY state. Between the first and the second states there is a short fragile period when getJobsSnapshot() will return nothing, but currentLevelOfDetail() will still return LoD of the latest job. This state is "okay", we just need to restart queue processing in this case. M +5 -2 libs/image/kis_simple_update_queue.cpp https://invent.kde.org/graphics/krita/commit/4af3922863f461bfc3852a1d2c538fbb65050a49 |