Bug 358846

Summary:	Crash/deadlock when painting while and animation plays
Product:	[Applications] krita	Reporter:	sylcat <syl.cat>
Component:	Animation	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	crash	CC:	animtim, halla, mneko
Priority:	NOR
Version First Reported In:	2.9.10
Target Milestone:	---
Platform:	unspecified
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description sylcat 2016-01-31 22:43:07 UTC

First, thanks Krita team, please keep improve this product!

As the summary says, if you are running Krita with OpenGL support unchecked in display options and then press play on the timeline so an animation loops a few frames, and then lastly try to make a stroke while the animation is playing, Krita will crash every time. If you stroke this way during animation play with OpenGL enabled Krita will just snap to the last frame and remain stable.

I'm very much hoping this reveals issues with brushstroke related crashes because Krita stops responding extremely often pretty much always while attempting random regular strokes (using anything from a cintiq pressure enabled pen to a regular mouse click and drag.) Krita crashes just as much with OpenGL activated as with not, I just can't yet find a reproducible method to crash with OpenGL on, it's very random.

When crashing on a stroke the cursor will just disappear and Krita will become unresponsive, requiring a task manager end process procedure to quit. I have tried operating from fresh boots with nothing else running and with many different settings configurations and the random crashes persist.

My intuition tells me stroke crashes happen most often when cursor movement is idle for a moment then on the redetection of movement there is a conflict somewhere. Before crashes I often see a fraction of a second where the cursor is following my motion like normal and then it disappears and I know the session is over.

Please prioritize this as it's a complete workflow killer. I have classified it as critical because I have lost hours of work to this bug chain. Awesome job on Krita so far guys, the animation setup is to die for, I just want it to stop...dying! :)

Reproducible: Always

Steps to Reproduce:
1. Deactivate OpenGL in display settings.
2. Make a few frames on the animation timeline and press play so it loops.
3. While it's playing touch a brush to the canvas and try to make a stroke.

Actual Results:
Crashes every time without fail.

Expected Results:
It should stop the animation and rest on the exact frame when an interrupting stroke is detected.

You guys rock.

Comment 1 Halla Rempt 2016-03-20 09:22:57 UTC

I don't get a crash, but I do get a hang when I try this:

0	QThreadPool::waitForDone(int)	/usr/lib64/libQt5Core.so.5		0x7fd929d52219	
1	KisUpdaterContext::waitForDone	kis_updater_context.cpp	188	0x7fd9301f8ebe	
2	KisUpdateScheduler::barrierLock	kis_update_scheduler.cpp	344	0x7fd93020a00f	
3	KisImage::barrierLock	kis_image.cc	379	0x7fd930217af5	
4	KisImageAnimationInterface::switchCurrentTimeAsync	kis_image_animation_interface.cpp	144	0x7fd9302148fe	
5	KisAnimationPlayer::uploadFrame	kis_animation_player.cpp	291	0x7fd93102ec7f	
6	QMetaObject::activate(QObject*, int, int, void**)	/usr/lib64/libQt5Core.so.5		0x7fd929f61cc6	
7	QTimer::timerEvent(QTimerEvent*)	/usr/lib64/libQt5Core.so.5		0x7fd929f6ef22	
8	QObject::event(QEvent*)	/usr/lib64/libQt5Core.so.5		0x7fd929f628bc	
9	QApplicationPrivate::notify_helper(QObject*, QEvent*)	/usr/lib64/libQt5Widgets.so.5		0x7fd92ac15e7c	
10	QApplication::notify(QObject*, QEvent*)	/usr/lib64/libQt5Widgets.so.5		0x7fd92ac1acc8	
11	KisApplication::notify	KisApplication.cpp	514	0x7fd930f7e150	
12	QCoreApplication::notifyInternal(QObject*, QEvent*)	/usr/lib64/libQt5Core.so.5		0x7fd929f31e95	
13	QTimerInfoList::activateTimers()	/usr/lib64/libQt5Core.so.5		0x7fd929f8877d	
14	??	/usr/lib64/libQt5Core.so.5		0x7fd929f88aa1	
15	g_main_context_dispatch	/usr/lib64/libglib-2.0.so.0		0x7fd924853c84	
16	??	/usr/lib64/libglib-2.0.so.0		0x7fd924853ed8	
17	g_main_context_iteration	/usr/lib64/libglib-2.0.so.0		0x7fd924853f7c	
18	QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)	/usr/lib64/libQt5Core.so.5		0x7fd929f88d6c	
19	QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)	/usr/lib64/libQt5Core.so.5		0x7fd929f2fd53	
20	QCoreApplication::exec()	/usr/lib64/libQt5Core.so.5		0x7fd929f378f6	
...	<More>

Comment 2 László Fazekas 2016-03-22 06:03:55 UTC

I see some reason to draw on a still layer during playback over a moving animation, but perhaps it's too difficult to realize. I think the easiest solution is to disable the drawing during playback. Clicking on the canvas should stop the playback only. Then drawing with a second stroke.

Comment 3 animtim 2016-10-03 12:44:55 UTC

Now if user click with stylus on the canvas while playing, it stops and return to last selected frame, which is perfectly fine behavior. Closing as fixed.