Project

General

Profile

Bug #11265

Memory handling issue in history undo

Added by Roman Lebedev over 2 years ago. Updated over 2 years ago.

Status:
Fixed
Priority:
Medium
Assignee:
Category:
Darkroom
Target version:
Start date:
10/27/2016
Due date:
% Done:

100%

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

Description

steps to reproduce:
  1. compile with asan. ./build.sh --asan might be enough
  2. load image in darkroom. (no history stack)
  3. change something in exposure iop
  4. duplicate exposure iop
  5. change something in second instance of exposure iop
  6. delete second instance of exposure iop
  7. press undo
  8. press undo
  9. crash (asan report) (line numbers may differ)

=================================================================
==12703==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900038c788 at pc 0x7fa20d8bd063 bp 0x7fffbe5bf070 sp 0x7fffbe5be820
READ of size 4 at 0x61900038c788 thread T0
    #0 0x7fa20d8bd062  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
    #1 0x7fa20873c301  (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x3b301)
    #2 0x7fa20874b64a  (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x4a64a)
    #3 0x7fa20d360d37 in dt_dev_write_history_item /home/lebedevri/darktable/src/develop/develop.c:541
    #4 0x7fa20d3647f2 in dt_dev_write_history /home/lebedevri/darktable/src/develop/develop.c:830
    #5 0x7fa1ef686c87 in pop_undo /home/lebedevri/darktable/src/libs/history.c:360
    #6 0x7fa20d526e6f in dt_undo_do_undo /home/lebedevri/darktable/src/views/undo.c:118
    #7 0x7fa1ec970064 in _darkroom_undo_callback /home/lebedevri/darktable/src/views/darkroom.c:2410
    #8 0x7fa20c651393  (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x230393)
    #9 0x7fa20ad70f74 in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xff74)
    #10 0x7fa20ad82f81  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x21f81)
    #11 0x7fa20ad8b66e in g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2a66e)
    #12 0x7fa20ad8bfae in g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2afae)
    #13 0x7fa20c52146e in gtk_accel_group_activate (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x10046e)
    #14 0x7fa20c522d6c in gtk_accel_groups_activate (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x101d6c)
    #15 0x7fa20c7c0f90 in gtk_window_activate_key (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x39ff90)
    #16 0x7fa20c7c1100  (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3a0100)
    #17 0x7fa20c65055b  (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22f55b)
    #18 0x7fa20ad70f74 in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xff74)
    #19 0x7fa20ad8337c  (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2237c)
    #20 0x7fa20ad8b66e in g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2a66e)
    #21 0x7fa20ad8bfae in g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2afae)
    #22 0x7fa20c79cd0b  (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x37bd0b)
    #23 0x7fa20c64d6f8  (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22c6f8)
    #24 0x7fa20c64f69d in gtk_main_do_event (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22e69d)
    #25 0x7fa20c15fb94  (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x36b94)
    #26 0x7fa20c190b51  (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x67b51)
    #27 0x7fa20cd7b7d6 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a7d6)
    #28 0x7fa20cd7ba3f  (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4aa3f)
    #29 0x7fa20cd7bd61 in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4ad61)
    #30 0x7fa20c64e804 in gtk_main (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22d804)
    #31 0x7fa20d4cd2be in dt_gui_gtk_run /home/lebedevri/darktable/src/gui/gtk.c:981
    #32 0x55a7db17aedc in main /home/lebedevri/darktable/src/main.c:25
    #33 0x7fa2050b92b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #34 0x55a7db17ad69 in _start (/opt/darktable/bin/darktable+0xd69)

0x61900038c788 is located 8 bytes inside of 1032-byte region [0x61900038c780,0x61900038cb88)
freed by thread T0 here:
    #0 0x7fa20d942a10 in free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1a10)
    #1 0x7fa20871bfaa in sqlite3_free (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x1afaa)

previously allocated by thread T0 here:
    #0 0x7fa20d942d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x7fa20874b3b6  (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x4a3b6)

SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) 
Shadow bytes around the buggy address:
  0x0c32800698a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c32800698b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c32800698c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c32800698d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c32800698e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c32800698f0: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3280069900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3280069910: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3280069920: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3280069930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c3280069940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==12703==ABORTING

So i think we somehow have an invalid reference to the module in undo after restoring module instance.

Associated revisions

Revision 3979c4f7
Added by Pascal Obry over 2 years ago

Fix crash in undo/redo for deleted instances.

Properly pass the module as user data to the history_invalidate_cb.
This is a bug introduced during the last code refactoring to move
undo/redo history specific code out of the generic undo/redo history.

Fixes #11265.

Revision af461c14
Added by Pascal Obry over 2 years ago

When entering the darkroom always clean-up the undo list.

We remove the DT_UNDO_HISTORY from the list when entering the darkroom as
we want to start with a clean undo list.

Closes #11265.
Closes #11373.

Revision 554ccc35
Added by Pascal Obry over 2 years ago

When entering the darkroom always clean-up the undo list.

We remove the DT_UNDO_HISTORY from the list when entering the darkroom as
we want to start with a clean undo list.

Closes #11265.
Closes #11373.

(cherry picked from commit af461c14183cccb294c586e4c132a7a582d82e1a)

History

#1 Updated by Pascal Obry over 2 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

Reproduced! Thanks for the reproducer. I'll have a look ASAP.

#2 Updated by Pascal Obry over 2 years ago

  • % Done changed from 10 to 100
  • Status changed from Confirmed to Fixed

#3 Updated by Roman Lebedev over 2 years ago

  • Target version set to 2.2.0

#4 Updated by Roman Lebedev over 2 years ago

  • Status changed from Fixed to In Progress
  • Priority changed from Low to Medium
  • % Done changed from 100 to 50

No it's not.

Basically the same steps.

  1. compile with asan. ./build.sh --asan might be enough
  2. load image in darkroom. (no history stack)
  3. change something in exposure iop
  4. repeat last step several times (10+)
  5. press undo and do not let go
  6. crash (asan report) (line numbers may differ)

Same bt.

#5 Updated by Pascal Obry over 2 years ago

Well, at least the original reproducer was fixed! Anyway, I'll have a look ASAP.

#6 Updated by Pascal Obry over 2 years ago

@Roman, I cannot reproduce with your scenario. I have made more than 10 modifications, did undo them one by one. Redid all one by one. Then I have also hold ctrl-z until all was undone, and then hold ctrl-y until all was redone... Did that many time, no crash! Is there another parameter in your side apart from the scenario you described?

#7 Updated by Roman Lebedev over 2 years ago

Pascal Obry wrote:

@Roman, I cannot reproduce with your scenario. I have made more than 10 modifications, did undo them one by one. Redid all one by one. Then I have also hold ctrl-z until all was undone, and then hold ctrl-y until all was redone... Did that many time, no crash! Is there another parameter in your side apart from the scenario you described?

I think it is a race condition, which is greatly influenced by the computer performance.
I used this to compile:

cd ~/darktable/build/ && rm -rf * && LDFLAGS="-fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -U_FORTIFY_SOURCE -fsanitize=address -fstack-protector-strong" CFLAGS="${LDFLAGS}" CXXFLAGS="${LDFLAGS}" CPPFLAGS="${LDFLAGS}" CC=gcc-6 CXX=g++-6 cmake -DCMAKE_INCLUDE_PATH:PATH=/opt/darktable/include -DCMAKE_LIBRARY_PATH:PATH=/opt/darktable/lib -DCMAKE_PREFIX_PATH:PATH=/opt/darktable -DCMAKE_INSTALL_PREFIX:PATH=/opt/darktable  ../ && make -j9

If it still does not work, i'd try -DCMAKE_BUILD_TYPE=Debug

#8 Updated by Pascal Obry over 2 years ago

  • Status changed from In Progress to Fixed
  • % Done changed from 50 to 100

Ok I finally was able to reproduce and the fix was then obvious. That's really another instance of the same bug discussed previously. I'm closing this ticket now hoping this is for good this time :)

Thanks a lot for catching this before the release BTW.

#9 Updated by Stefan Schöfegger over 2 years ago

I get the same error with 2.2

$ darktable
[dev_read_history] database history for image `DSC07029.ARW' seems to be corrupted! =================================================================
19414ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000faeb88 at pc 0x7fbb9d52f063 bp 0x7ffea99af540 sp 0x7ffea99aecf0
READ of size 4 at 0x619000faeb88 thread T0
#0 0x7fbb9d52f062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
#1 0x7fbb9845f371 (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x3b371)
#2 0x7fbb9846e6ca (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x4a6ca)
#3 0x7fbb9cf2762b in dt_dev_write_history_item /home/steve/prj/darktable_schenlap/src/develop/develop.c:541
#4 0x7fbb9cf2a471 in dt_dev_write_history /home/steve/prj/darktable_schenlap/src/develop/develop.c:830
#5 0x7fbb51378ea5 in pop_undo /home/steve/prj/darktable_schenlap/src/libs/history.c:360
#6 0x7fbb9d07d1c2 in dt_undo_do_undo /home/steve/prj/darktable_schenlap/src/views/undo.c:118
#7 0x7fbb7ccebf12 in _darkroom_undo_callback /home/steve/prj/darktable_schenlap/src/views/darkroom.c:2422
#8 0x7fbb9c31d853 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x230853)
#9 0x7fbb9aa5ef74 in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xff74)
#10 0x7fbb9aa70f81 (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x21f81)
#11 0x7fbb9aa7966e in g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2a66e)
#12 0x7fbb9aa79fae in g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2afae)
#13 0x7fbb9c1ed5be in gtk_accel_group_activate (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x1005be)
#14 0x7fbb9c1eeebc in gtk_accel_groups_activate (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x101ebc)
#15 0x7fbb9c48d660 in gtk_window_activate_key (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3a0660)
#16 0x7fbb9c48d7d0 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3a07d0)
#17 0x7fbb9c31ca1b (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22fa1b)
#18 0x7fbb9aa5ef74 in g_closure_invoke (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0xff74)
#19 0x7fbb9aa7137c (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2237c)
#20 0x7fbb9aa7966e in g_signal_emit_valist (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2a66e)
#21 0x7fbb9aa79fae in g_signal_emit (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2afae)
#22 0x7fbb9c4693db (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x37c3db)
#23 0x7fbb9c319bb8 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22cbb8)
#24 0x7fbb9c31bb5d in gtk_main_do_event (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22eb5d)
#25 0x7fbb9be2cbf4 (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x36bf4)
#26 0x7fbb9be5dbe1 (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x67be1)
#27 0x7fbb9ca4c7f6 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a7f6)
#28 0x7fbb9ca4ca5f (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4aa5f)
#29 0x7fbb9ca4cd81 in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4ad81)
#30 0x7fbb9c31acc4 in gtk_main (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22dcc4)
#31 0x7fbb9d032734 in dt_gui_gtk_run /home/steve/prj/darktable_schenlap/src/gui/gtk.c:981
#32 0x560cc2e69d3b in main /home/steve/prj/darktable_schenlap/src/main.c:25
#33 0x7fbb9507a2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#34 0x560cc2e69d89 in _start (/opt/darktable/bin/darktable+0xd89)

AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
Shadow bytes around the buggy address:
0x0c32801edd20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c32801edd70: fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edd90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801edda0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801eddb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c32801eddc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
19414ABORTING

Build with

cd build/ && rm -rf * && LDFLAGS="-fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-common -U_FORTIFY_SOURCE -fsanitize=address -fstack-protector-strong" CFLAGS="${LDFLAGS}" CXXFLAGS="${LDFLAGS}" CPPFLAGS="${LDFLAGS}" CC=gcc-6 CXX=g++-6 cmake -DCMAKE_INCLUDE_PATH:PATH=/opt/darktable/include -DCMAKE_LIBRARY_PATH:PATH=/opt/darktable/lib -DCMAKE_PREFIX_PATH:PATH=/opt/darktable -DCMAKE_INSTALL_PREFIX:PATH=/opt/darktable  ../ && make
sudo cmake --build "FOOBAR/build" --target install -- -j8                                                                                                                                         

I can reproduce it very fast. Open crop module press CTRL+Z  and do a few double clicks and press CTRL+Z again when in darkroom -> crash or hang

#10 Updated by Roman Lebedev over 2 years ago

  • Status changed from Fixed to Confirmed
  • Target version changed from 2.2.0 to 2.4.0
  • % Done changed from 100 to 10

Third time the same bt, there must be something really wrong going on...

#11 Updated by Pascal Obry over 2 years ago

Good news I can reproduce!

#12 Updated by Pascal Obry over 2 years ago

Should now be fixed.

#13 Updated by Pascal Obry over 2 years ago

  • Target version changed from 2.4.0 to Candidate for next patch release

#14 Updated by Pascal Obry over 2 years ago

  • % Done changed from 10 to 100
  • Status changed from Confirmed to Fixed

#15 Updated by Roman Lebedev over 2 years ago

  • Target version changed from Candidate for next patch release to 2.4.0

Also available in: Atom PDF