Bug #11956

spot removal and denoise (bilateral filter) crashes dt

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

Target version:
Start date:
Due date:
% Done:


Affected Version:
git master branch
hardware architecture:



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.


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


#1 Updated by Tobias Ellinghaus 5 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 5 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

#3 Updated by Tobias Ellinghaus 5 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 5 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 5 months ago

This is a version without the list copy

Also available in: Atom PDF