Project

General

Profile

Bug #11956

spot removal and denoise (bilateral filter) crashes dt

Added by Edgardo Hoszowski 11 months ago. Updated 11 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
01/23/2018
Due date:
% Done:

0%

Affected Version:
git master branch
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Hi,

When spot removal is used and I create multiple instances of denoise (bilateral filter) with drawn masks dt crashes.

Steps to duplicate:

1. discard history stack on an image
2. enter darkroom and add a circle on spot removal
3. without enabling it, set blend mode to drawn mask in denoise (bilateral filter)
4. add a circle
5. create a new instance of denoise (bilateral filter)
6. repeat steps 3-4-5 until dt crashes

Steps 3-4-5 must be done while darkroom is working.

I was able to duplicate it with the equalizer instead of the denoise (bilateral filter), but I couldn't duplicate it without the spot removal active.

Build from master on xubuntu 16.04

Attached is a backtrace.

Regards,
Edgardo.

darktable_bt_UDO5CZ.txt Magnifier (219 KB) Edgardo Hoszowski, 01/23/2018 03:19 PM

History

#1 Updated by Tobias Ellinghaus 11 months ago

That sounds and looks like some race condition where the pipe changed while it was used in mask code. I don't know that code at all, maybe someone else has an idea what exactly is going on?

#2 Updated by Edgardo Hoszowski 11 months ago

I think I found it, in this case the dev->iop list is modified while the pipe is running. I have a potential fix in the following branch if you are interested

https://github.com/edgardoh/darktable/tree/Bug_11956

#3 Updated by Tobias Ellinghaus 11 months ago

Instead of havinf a copy of the list one should stop changing the list while it's running.

#4 Updated by Edgardo Hoszowski 11 months ago

The code is trying to stop the pipe when the iop list is modified, but there are gaps when the pipe is not locked, so it still process the nodes and those get out of synch with the iop.
A lock could (and probably should) be added to the iop's, but that will not guaranty that the nodes don't get out of synch, and locking the pipe from the nodes creation to the exit will make dt less responsive.
Having this copy of the iop allows to ensure that the nodes and iop are in synch. Also it don't take much resources or affects performance.

Something similar with copy of the nodes list, sometimes the nodes are re-created while the pipe is running, having a copy saves from adding more locks and/or wait until the pipe finish.

#5 Updated by Edgardo Hoszowski 11 months ago

This is a version without the list copy

https://github.com/edgardoh/darktable/tree/Bug_11956_2

Also available in: Atom PDF