I've been looking at this today and I've got a theory.
Could the LRU eviction case in dt_dev_pixelpipe_cache_get() (
https://github.com/darktable-org/darktable/blob/release-2.4.0/src/develop/pixelpipe_cache.c#L172
) be causing a use-after-free on &input in dt_dev_pixelpipe_process_rec() ?
That "input" pointer is set by a recursive call ...
if(dt_dev_pixelpipe_process_rec(pipe, dev, &input, &cl_mem_input,
&input_format, &roi_in,
g_list_previous(modules), g_list_previous(pieces), pos - 1))
return 1;
https://github.com/darktable-org/darktable/blob/release-2.4.0/src/develop/pixelpipe_hb.c#L718
... and in some cases it gets it from dt_dev_pixelpipe_cache_get() in
that recursive call
https://github.com/darktable-org/darktable/blob/release-2.4.0/src/develop/pixelpipe_hb.c#L659
... which is followed by potentially more recursion and thus presumably
several more calls to dt_dev_pixelpipe_cache_get() as it goes deeper,
any of which has the potential to free() (or cause an overwrite of)
anything it previously returned.
After the recursion, dt_dev_pixelpipe_cache_get() is called again...
if(!strcmp(module->op, "gamma"))
(void)dt_dev_pixelpipe_cache_get_important(&(pipe->cache), hash,
bufsize, output, out_format);
else
(void)dt_dev_pixelpipe_cache_get(&(pipe->cache), hash, bufsize,
output, out_format);
https://github.com/darktable-org/darktable/blob/release-2.4.0/src/develop/pixelpipe_hb.c#L740
Then we have...
module->process(module, piece, input, *output, &roi_in, roi_out);
https://github.com/darktable-org/darktable/blob/release-2.4.0/src/develop/pixelpipe_hb.c#L1628
... (and several other potential calls in the opencl case) by which time
&input may have been freed.
I see there are mutexes around all the cache accesses too, which implies
that some other thread might be accessing the cache, in which case maybe
that thread is causing an LRU eviction.
Any thoughts?
cheers
David
On 30/12/17 03:26, Tobias Ellinghaus wrote:
Am Freitag, 29. Dezember 2017, 05:47:43 CET schrieb Alex Delaforce:
Hi all,
this is my first bug report through the dev list - please let me know if I
am not following the correct protocol
Version
DT 2.4.0 - Windows version
Action
Open DT, then double click on CR2 file shown top left on the lighttable
display
OR
Open DT, then click on CR2 file shown top left on the lighttable display
then select darkroom from top right link
Doesnt happen every time - seems to be related to
- after DT has recently been opened, once I get a photo in the darkroom
mode successfully the fault doesn't seem to recur during the session.
- may be a particular couple of photos - CR2s, doesn't seem to occur with
JPEG
The error dialogue box is
Error!
An unhandled exception occured.
Backtrace will be written to .... etc.
A couple of the backtrace files are attached.
Thanks. We have reports about that crash since a while but so far we have no
idea what might be causing it, and Windows doesn't give us very useful
backtraces either.
Should you be able to find a reliable set of steps to reproduce it we would be
more than happy to hear them.
Thanks Devs for your excellent work.
Alex
Tobias
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
