Bug #12125

Crash in lighttable, scrolling through images (malloc invalid chunk size)

Added by Neil Schemenauer 10 months ago. Updated 5 months ago.

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


Affected Version:
hardware architecture:


I looked through the open bugs, I think this might be different that the other reported bugs. I'm using the Debian package 2.4.2-1, AMD64.

The crash seems perfectly repeatable. Go into the lighttable, select a recently used collection, scroll with the mouse wheel a bit and it crashes.

$ gdb /usr/bin/darktable
malloc_consolidate(): invalid chunk size

Thread 12 "worker 7" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffc9ffb700 (LWP 10312)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff7318231 in __GI_abort () at abort.c:79
#2 0x00007ffff73597b7 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7ffff74620f3 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff735fd5a in malloc_printerr (
str=str@entry=0x7ffff74639b0 "malloc_consolidate(): invalid chunk size")
at malloc.c:5350
#4 0x00007ffff736005e in malloc_consolidate (av=av@entry=0x7fffac000020)
at malloc.c:4441
#5 0x00007ffff7361847 in _int_free (av=0x7fffac000020, p=0x7fffac043650,
have_lock=<optimized out>) at malloc.c:4362
#6 0x00007ffff79c4c16 in dt_dev_free_history_item ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/
#7 0x00007ffff79c4c90 in dt_dev_cleanup ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/
#8 0x00007ffff7978878 in dt_imageio_export_with_flags ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/
#9 0x00007ffff799841f in dt_mipmap_cache_get_with_caller ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/
#10 0x00007ffff79c0e0f in ?? ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/
#11 0x00007ffff79b948d in ?? ()
from /usr/bin/../lib/x86_64-linux-gnu/darktable/


#1 Updated by Neil Schemenauer 10 months ago

I just built a new version from the git master (6fe1d0f2afc964f08c5a15005476fe021c70a2cb). I can't reproduce the crash so maybe it has been fixed.

#2 Updated by Tobias Ellinghaus 10 months ago

Hard to tell without a complete backtrace and no debug symbols.

#3 Updated by Neil Schemenauer 9 months ago

This is not exactly the same traceback but I trigger it the same way. Unfortunately "rr" doesn't work, otherwise I could use reverse-debugging to trace the execution in reverse. It looks to me like that problem is related to the "error:" block in dt_imageio_export_with_flags(). In the "error:" block, there is a call:


That was added in commit ba07786953cd54f50e9025804c1765e2e906681e

Author: Roman Lebedev <>
Date:   Thu Jul 9 14:03:03 2015 +0300

    dt_imageio_export_with_flags(): rework error handling

    When we fail to process thumbnail (e.g. raw can no be loaded by RS,
    or corrupted PNG), we would not call dt_dev_pixelpipe_cache_cleanup(),
    thus leaking a _LOT_ of memory. (~320Mb per 20Mpix image)

It looks to me like 'pipe' is not in a state that 'dt_dev_pixelpipe_cleanup' can handle. Specifically, the cache->data array contains poisoned pointers.

(gdb) set environment LD_PRELOAD /usr/lib/
(gdb) run
Thread 7 "worker 2" received signal SIGBUS, Bus error.
0x00007ffff7b92765 in ?? () from /usr/lib/
(gdb) up
#1  0x00007ffff7ba3fcf in tc_cfree ()
   from /usr/lib/
(gdb) up
#2  0x00007ffff7789c5d in dt_dev_pixelpipe_cache_cleanup (
    at /home/nas/pkg/darktable/src/develop/pixelpipe_cache.c:72
72      for(int k = 0; k < cache->entries; k++) dt_free_align(cache->data[k]);

(gdb) up
#2  0x00007ffff7789c5d in dt_dev_pixelpipe_cache_cleanup (
    at /home/nas/pkg/darktable/src/develop/pixelpipe_cache.c:72
72      for(int k = 0; k < cache->entries; k++) dt_free_align(cache->data[k]);
(gdb) l
67      return 0;
68    }
70    void dt_dev_pixelpipe_cache_cleanup(dt_dev_pixelpipe_cache_t *cache)
71    {
72      for(int k = 0; k < cache->entries; k++) dt_free_align(cache->data[k]);
73      free(cache->data);
74      free(cache->dsc);
75      free(cache->hash);
76      free(cache->used);
(gdb) p cache->data
$1 = (void **) 0x5555699dcee0
(gdb) p *cache->data
$2 = (void *) 0xcdcdcdcdcdcdcdcd

How that happens exactly, I'm not able to determine. I'm not able to reproduce it now. I built a "Debug" version of darktable and could not trigger it. I wonder if the thumbnails have been successfully cached and I'm no longer hitting that error case.

#4 Updated by Neil Schemenauer 9 months ago

I rebuild the git source from master and can no longer reproduce this (commit ace20731fe725caa91076888f7bda37bc27e7301). Its possible that the offending thumbnail was re-built successfully somehow. However, removing the ~/.cache/darktable folder and running darktable-generate-cache did not trigger a crash either. I'd say we should close this bug.

#5 Updated by Tobias Ellinghaus 9 months ago

  • Status changed from New to Closed: invalid

Please make sure to tell us if you can find out any more.

#6 Updated by Roman Lebedev 5 months ago

  • Target version set to 2.6.0

Also available in: Atom PDF