| Summary: | Crash when adding in multiple frame columns. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | wolthera <griffinvalley> |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | antti.savo, etienne.noss+kdebugs, halla |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/kde/krita/commit/139c89282078be6e65c2e44650abacd0f76c2ec6 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
wolthera
2019-03-21 15:10:58 UTC
I'm unable to reproduce this. Is there more to this crash than what I've done in the video? Do you have something extra in the scenes? Any hints would be appreciated. https://youtu.be/RHP2O5nZi9A It might be caused by this being an 'address sanitizer' build, so I (a Krita developer), would prefer a Krita developer to take a look at the backtrace to see if something can be done. Thanks for your concern however :) I've been having what I believe to be the same bug (i.e. the same assertion fails) using a debug build of the Debian package in testing.
I'm new to reporting bugs here and I couldn't get drkonqi to work, so tell me if there is missing info. I have the core dump.
Krita version: 4.1.7.101 (built with debug symbols from Debian source package)
Operating system: Debian buster/sid, Linux 4.19.28
Steps to reproduce:
- Open an animation with frames
- select some frames
- drag & drop them around
- sometimes it crashes
Backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f612d7e1535 in __GI_abort () at abort.c:79
#2 0x00007f612db9f9a7 in QMessageLogger::fatal(char const*, ...) const () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3 0x00007f612ec5fd6f in kis_assert_common (assertion=0x7f612ca1bf84 "m_frames.contains(frameId)",
file=0x7f612ca1bee8 "/home/etienne/perso/krita/krita-4.1.7+dfsg/libs/image/kis_paint_device.cc", line=466, throwException=false, isIgnorable=false)
at ./libs/global/kis_assert.cpp:90
#4 0x00007f612ec60087 in kis_assert_recoverable (assertion=0x7f612ca1bf84 "m_frames.contains(frameId)",
file=0x7f612ca1bee8 "/home/etienne/perso/krita/krita-4.1.7+dfsg/libs/image/kis_paint_device.cc", line=466) at ./libs/global/kis_assert.cpp:103
#5 0x00007f612c8e565a in KisPaintDevice::Private::currentFrameData (this=0x561530be56a0) at ./libs/image/kis_paint_device.cc:466
#6 0x00007f612c8e57ea in KisPaintDevice::Private::currentNonLodData (this=0x561530be56a0) at ./libs/image/kis_paint_device.cc:485
#7 0x00007f612c8e5a9e in KisPaintDevice::Private::currentData (this=0x561530be56a0) at ./libs/image/kis_paint_device.cc:519
#8 0x00007f612c8e3898 in KisPaintDevice::Private::colorSpace (this=0x561530be56a0) at ./libs/image/kis_paint_device.cc:116
#9 0x00007f612c8dfb54 in KisPaintDevice::colorSpace (this=0x561530be5ba0) at ./libs/image/kis_paint_device.cc:1976
#10 0x00007f612c8dc294 in KisPaintDevice::defaultPixel (this=0x561530be5ba0) at ./libs/image/kis_paint_device.cc:1463
#11 0x00007f612c8e7031 in KisPaintDevice::Private::KisPaintDeviceStrategy::extent (this=0x561530be5c70) at ./libs/image/kis_paint_device_strategies.h:55
#12 0x00007f612c8db98d in KisPaintDevice::extent (this=0x561530be5ba0) at ./libs/image/kis_paint_device.cc:1207
#13 0x00007f612c6cb840 in KisPainter::Private::tryReduceSourceRect (this=0x7f60ec0008d0, srcDev=0x561530be5ba0, srcRect=0x7f6105d8d930, srcX=0x7f6105d8d8a4,
srcY=0x7f6105d8d8a0, srcWidth=0x7f6105d8d9a0, srcHeight=0x7f6105d8d9a8, dstX=0x7f6105d8d8b4, dstY=0x7f6105d8d8b0) at ./libs/image/kis_painter.cc:463
#14 0x00007f612c6ce38e in KisPainter::bitBltImpl<false> (this=0x7f6105d8db60, dstX=0, dstY=0, srcDev=..., srcX=0, srcY=0, srcWidth=74, srcHeight=74)
at ./libs/image/kis_painter.cc:641
#15 0x00007f612c6ba141 in KisPainter::bitBlt (this=0x7f6105d8db60, dstX=0, dstY=0, srcDev=..., srcX=0, srcY=0, srcWidth=74, srcHeight=74)
at ./libs/image/kis_painter.cc:773
#16 0x00007f612c6ba242 in KisPainter::bitBlt (this=0x7f6105d8db60, pos=..., srcDev=..., srcRect=...) at ./libs/image/kis_painter.cc:779
#17 0x00007f612c860ccb in KisLayerProjectionPlane::apply (this=0x561530be59f0, painter=0x7f6105d8db60, rect=...)
at ./libs/image/kis_layer_projection_plane.cpp:99
#18 0x00007f612c7f4a92 in KisAsyncMerger::compositeWithProjection (this=0x561530bb6f08, leaf=..., rect=...) at ./libs/image/kis_async_merger.cpp:350
#19 0x00007f612c7efccc in KisAsyncMerger::startMerge (this=0x561530bb6f08, walker=..., notifyClones=true) at ./libs/image/kis_async_merger.cpp:274
#20 0x00007f612c9eed4e in KisUpdateJobItem::runMergeJob (this=0x561530bb6ec0)
at ./obj-x86_64-linux-gnu/libs/image/kritaimage_autogen/EWIEGA46WW/../../../../../libs/image/kis_update_job_item.h:117
#21 0x00007f612c9eeb99 in KisUpdateJobItem::run (this=0x561530bb6ec0)
at ./obj-x86_64-linux-gnu/libs/image/kritaimage_autogen/EWIEGA46WW/../../../../../libs/image/kis_update_job_item.h:85
#22 0x00007f612dbd9021 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007f612dbe0aa7 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007f612b3cefa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#25 0x00007f612d8b882f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Yes, that's the same assert. It's quite weird though, because these asserts shouldn't be visible in distribution builds. If that can be of any use: I built it from the Debian package sources in order to get a useable backtrace, since there are no debug symbols for Krita in the Debian repositories. I don't know if that counts as a distribution build ? I used DEB_BUILD_OPTIONS="nostrip noopt parallel=8" fakeroot apt-get -b source krita and installed the resulting .deb package. Would it be useful if I built it without the asserts and/or from the Krita repository and tried to reproduce ? Git commit db811bc82a3a067bedcbaddceb149f05c5d5bf82 by Dmitry Kazakov. Committed on 16/05/2019 at 09:49. Pushed by dkazakov into branch 'master'. Fix assert when manipulating animation frames Every frame add/move/delete command issues canvas updates. We shouldn't let these updates to run until all manipulations with m_frames are finished. Otherwise there will be non-thread-safe access to frames storage. M +3 -1 plugins/dockers/animation/kis_animation_curves_model.cpp M +6 -2 plugins/dockers/animation/kis_animation_utils.cpp M +5 -2 plugins/dockers/animation/kis_time_based_item_model.cpp M +9 -3 plugins/dockers/animation/timeline_frames_model.cpp https://invent.kde.org/kde/krita/commit/db811bc82a3a067bedcbaddceb149f05c5d5bf82 Git commit 139c89282078be6e65c2e44650abacd0f76c2ec6 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 17/05/2019 at 08:12. Pushed by rempt into branch 'krita/4.2'. Fix assert when manipulating animation frames Every frame add/move/delete command issues canvas updates. We shouldn't let these updates to run until all manipulations with m_frames are finished. Otherwise there will be non-thread-safe access to frames storage. M +3 -1 plugins/dockers/animation/kis_animation_curves_model.cpp M +6 -2 plugins/dockers/animation/kis_animation_utils.cpp M +5 -2 plugins/dockers/animation/kis_time_based_item_model.cpp M +9 -3 plugins/dockers/animation/timeline_frames_model.cpp https://invent.kde.org/kde/krita/commit/139c89282078be6e65c2e44650abacd0f76c2ec6 |