Bug 405879

Hi,

Could you please also install the debug symbols? See https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw -- easiest is to download both zip files from the nightlies page. Right now we can see there's an illegal access in the image library, but not where.

Created attachment 119046 [details]
attachment-32012-0.html

okay, i downloaded but how should i use them?

вт, 26 мар. 2019 г. в 13:06, Boudewijn Rempt <bugzilla_noreply@kde.org>:

> https://bugs.kde.org/show_bug.cgi?id=405879
>
> --- Comment #1 from Boudewijn Rempt <boud@valdyas.org> ---
> Hi,
>
> Could you please also install the debug symbols? See
> https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw
> --
> easiest is to download both zip files from the nightlies page. Right now
> we can
> see there's an illegal access in the image library, but not where.
>
> --
> You are receiving this mail because:
> You reported the bug.
> You voted for the bug.

Simply copy the contents of the debug package into the unzipped krita folder. The page I linked to has some more information.

Now i should use it until i get the crash again? okay.

Right :-)

I just received the crash twice, but it acts like freeze and then windows destroys the task, crash log doesn't get created, how i can get the crash log? or in debug version it is not located at appdata/local?

It is very easy to get crash, i just right click on opacity bar and then specify the layer opacity to random values like 90/40/30/5, then pressing enter to apply, and then left click on canvas to draw, then repeat it x10 times and less than in minute i receive the freezing, but sadly it doesn't actually crash so i am not receiving the crash log.

Ah i understand, the log file is from the other crash, currently i am reporting the freeze bug, i just found how to trigger crash but that's different thing, crash happens when i usie gmic with specific settings, but that freeze bug bothers me much more, its more critical.

Created attachment 119047 [details]
Updated crash log

Here i include the updated log with gmic crash but that's second bug i found, i am still looking for that layer freeze bug, if its possible please fix it, it is very easy to reproduce but it never gets to actual crash.

Created attachment 119051 [details]
attachment-5873-0.html

Are there any chance about this bug being fixed? If yes, then how long it
could take?

вт, 26 мар. 2019 г. в 13:09, Sam <godofwar8080@gmail.com>:

> okay, i downloaded but how should i use them?
>
> вт, 26 мар. 2019 г. в 13:06, Boudewijn Rempt <bugzilla_noreply@kde.org>:
>
>> https://bugs.kde.org/show_bug.cgi?id=405879
>>
>> --- Comment #1 from Boudewijn Rempt <boud@valdyas.org> ---
>> Hi,
>>
>> Could you please also install the debug symbols? See
>> https://docs.krita.org/en/reference_manual/dr_minw_debugger.html#dr-minw
>> --
>> easiest is to download both zip files from the nightlies page. Right now
>> we can
>> see there's an illegal access in the image library, but not where.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>> You voted for the bug.
>
>

We'll try to fix it for the 4.2 release, which is currently planned for May.

Thanks! That's good to hear.

In the meantime, it might be a better idea to use the released version of Krita (4.1.7) for production work. We're right now trying to update the nightly builds to a new version of the development framework and the road is really rocky.

I understand, but the freezing bug exist there too, so i am working with cautions right now, more testing than working, that's why i switched to nightly versions to check if bug was already fixed in the latest build, and sadly it is still here, however in all other aspects nightly build works fine for now, i will update and test nightly builds further to check out for more bugs, it may help you to fix them out.

Git commit 44337c52c090189d4fe3fa117178f92471d1ff06 by Dmitry Kazakov.
Committed on 27/03/2019 at 09:12.
Pushed by dkazakov into branch 'master'.

Add sanity checks to KisProjectionLeaf::Private::node

It looks like one of the users managed to catch such a case,
when the node has been deleted while the updates were still
holding a pointer to it. I don't know how it was reproduced,
and, technically, our system should not allow such cases.

Therefore, this patch just converts the node pointer into a
weak pointer and adds a sanity check assert into KisAsyncMerger.

I hope we'll catch this assert one day and get better report
about what triggered it.

M  +8    -1    libs/image/kis_async_merger.cpp
M  +8    -8    libs/image/kis_projection_leaf.cpp

https://commits.kde.org/krita/44337c52c090189d4fe3fa117178f92471d1ff06

Well it seems weird to me that nobody found this bug before, i am new user in krita and using it just for 2 weeks, and received this freeze bug so many times until i realized the steps that triggered it, bug was very unpleasant because you lose all the work you made if you forgot to save, now i can reproduce freeze by just few clicks, well at least i can avoid triggering it now.

I still haven't managed to actually reproduce the issue myself. I must be misunderstanding something! Could you perhaps make a screen recording showing what you're doing exactly?

Created attachment 119081 [details]
This is the video how to get the freezing bug.

Hello again, here i captured video by bandicam and added subtitle hint to explain better, as you can see i can get this bug just in 20 seconds, this happens same in stable build and in nightly builds.

Found out more info, bug can be triggered immediatly and less than in 1 seconds.

Steps are below.
If we right click on opacity bar, typing the value and quickly after that left click on canvas freeze happens.
It depends on timing, if we do it very quickly the krita freezes immediatly, 
so if we skip pressing enter to apply specified layer opacity and left click it freezes,
or even if we press enter to apply and simultaneously click left mouse to drag it also freezes.

So the trigger is when layer opacity is changed by specific number,
and simultaneously after that we try to draw on canvas it makes krita freeze.

I hope this additional info helps you to find this bug better.

Created attachment 119112 [details]
attachment-405-0.html

Hello again, i am not sure if sanity check was the fix for it, but i just
tried latest 504* nightly build, and bug still persist there,
it seems to me it is even more easy and quickly to receive now, took me few
clicks and only 4 seconds to catch freeze.

I still hope this will be fixed soon.

ср, 27 мар. 2019 г. в 16:24, Boudewijn Rempt <bugzilla_noreply@kde.org>:

> https://bugs.kde.org/show_bug.cgi?id=405879
>
> --- Comment #17 from Boudewijn Rempt <boud@valdyas.org> ---
> I still haven't managed to actually reproduce the issue myself. I must be
> misunderstanding something! Could you perhaps make a screen recording
> showing
> what you're doing exactly?
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You reported the bug.

That sanity check commit was only for one of the crashes in the crash log you provided.

Aah, thanks for explanation, did you able to reproduce the freeze bug like in the video?

Yes, I've now been able to reproduce it. The hang only occurs if you use a stylus, not with a mouse, it seems. And I guess most people don't encounter it, because most people move the slider, instead of typing in a value.

Note: this is not a regression, this happened in 3.0 already.

I can confirm the bug. The problem happens because the "change opacity" signal arrives after the user starts a stroke. "Change opacity" requets a barrier lock over the image and dives into sleep forever.

Created attachment 119172 [details]
attachment-19374-0.html

Can you please tell anything about when this will be fixed?

пт, 29 мар. 2019 г. в 17:17, Dmitry Kazakov <bugzilla_noreply@kde.org>:

> https://bugs.kde.org/show_bug.cgi?id=405879
>
> Dmitry Kazakov <dimula73@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |dimula73@gmail.com
>
> --- Comment #25 from Dmitry Kazakov <dimula73@gmail.com> ---
> I can confirm the bug. The problem happens because the "change opacity"
> signal
> arrives after the user starts a stroke. "Change opacity" requets a barrier
> lock
> over the image and dives into sleep forever.
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You reported the bug.

Like I said, it probably will be fixed when we release 4.2. 

Sure, it needs fixing, but it's not a bug of the first priority because very few people have actually the habit of clicking on the canvas within milliseconds of changing the layer's opacity -- and changing the layer opacity is also not something people usually do every five minutes. 

Then again, the bug has been present since Krita 3.0 at least. If this would be something that many people run into, we'd have had bug reports about it before.

In any case, we're an open source project, not a company, we don't do paid support, we don't let ourselves be pressured into reprioritizing our todo list. 

We found the cause for this issue, we have confirmed it, and that's already quite good progress.

Git commit b10a1bbb6d665243717998a5f46756f0755c8600 by Dmitry Kazakov.
Committed on 01/04/2019 at 13:40.
Pushed by dkazakov into branch 'master'.

Fix a hangup when starting painting too quickly after changing opacity

Opacity and Blending mode are now changed using a stroke. Therefore,
opacity change will arrive **after** the stroke has finished :)

M  +14   -7    libs/ui/kis_node_commands_adapter.cpp
M  +4    -10   libs/ui/kis_node_manager.cpp
M  +2    -2    libs/ui/kis_node_manager.h
M  +4    -2    plugins/dockers/layerdocker/LayerBox.cpp

https://commits.kde.org/krita/b10a1bbb6d665243717998a5f46756f0755c8600

Created attachment 119199 [details]
attachment-28754-0.html

Thanks for fixing it! You deserve the support.

пн, 1 апр. 2019 г. в 17:55, Dmitry Kazakov <bugzilla_noreply@kde.org>:

> https://bugs.kde.org/show_bug.cgi?id=405879
>
> Dmitry Kazakov <dimula73@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>          Resolution|---                         |FIXED
>       Latest Commit|                            |
> https://commits.kde.org/kri
>                    |
> |ta/b10a1bbb6d665243717998a5
>                    |                            |f46756f0755c8600
>              Status|CONFIRMED                   |RESOLVED
>
> --- Comment #28 from Dmitry Kazakov <dimula73@gmail.com> ---
> Git commit b10a1bbb6d665243717998a5f46756f0755c8600 by Dmitry Kazakov.
> Committed on 01/04/2019 at 13:40.
> Pushed by dkazakov into branch 'master'.
>
> Fix a hangup when starting painting too quickly after changing opacity
>
> Opacity and Blending mode are now changed using a stroke. Therefore,
> opacity change will arrive **after** the stroke has finished :)
>
> M  +14   -7    libs/ui/kis_node_commands_adapter.cpp
> M  +4    -10   libs/ui/kis_node_manager.cpp
> M  +2    -2    libs/ui/kis_node_manager.h
> M  +4    -2    plugins/dockers/layerdocker/LayerBox.cpp
>
> https://commits.kde.org/krita/b10a1bbb6d665243717998a5f46756f0755c8600
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You reported the bug.

*** Bug 395278 has been marked as a duplicate of this bug. ***

Created attachment 123205 [details]
Krita Canvas Problem

This video shows a problem I've been having with Krita since I first updated to 4.2.6(and most recently 4.2.7.1). It just happens at random, but the only thing that makes it go away is restarting my computer or turning it off and back on. Basically, when I zoom in or out it won't show the action until I do some random thing, same with the brush strokes, they won't show until I do some random thing. Can someone fix this for the next Krita update?

dillonwright13@gmail.com - make a new bug report, this one was marked "fixed" for a reason (Dmitry found the cause of the bug that the creator of this bug report had and the bug was fixed in the code). Finding a resolved bug report that sounds kind of similar (but is about a different issue) won't help developers. Every separate issue needs to be in a separate bug report. Also "assignee" is the person who is supposed to be *fixing* the bug.

frutidoody@gmail.com - do not change the version of the program in a bug report from an older to a newer one. "Version" means "the first version I noticed the bug in".

I can't draw all of sudden, I cut and pasted everything into a new document and was able to paint and draw on all layers and now I can't again, I've reinstalled Krita, but it didn't fix it.

The program just now crashed and deleted all my art pieces except 1. Anybody got a fix for that?

shanethepain3000@gmail.com
Sean Sosa
This is not a place for user support, this is a developers' website. Please head over to krita-artists.org and write a post about your issues in "Advice & Support" part of the forum.