crash with 1.3 when double clicking perspective corrected image to get at 100 %

[Danny Heijl]

Windows 10 Pro version 1909 build 18363.815, with ART generic build 1.3

Canon CR3 raw file (attached)

applied lens geometry correction (geometry and vignetting)

applied automatic perspective correction to get verticals vertical (middle icon)

double clicked on the image to get at 100 % magnification

ART vanishes.

gdb backtrace and raw file included.

[Danny Heijl]

Same happens on Linux with a build of the recent master (no debug):

double free or corruption (out)

Thread 87 "ART" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffbdffb700 (LWP 3564)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet.

‌

[Danny Heijl]

gdb backtrace of the debug build:

double free or corruption (out)

Thread 66 "ART" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdc971700 (LWP 8030)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet.
(gdb) bt
#0 0x00007ffff217de97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff217f801 in __GI_abort () at abort.c:79
#2 0x00007ffff21c8897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff22f5b9a "%s\n")
at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff21cf90a in malloc_printerr (str=str@entry=0x7ffff22f7870 "double free or corruption (out)") at malloc.c:5350
#4 0x00007ffff21d6e75 in _int_free (have_lock=0, p=0x7fffcc7f9500, av=0x7ffff252ac40 <main_arena>) at malloc.c:4278
#5 0x00007ffff21d6e75 in __GI___libc_free (mem=0x7fffcc7f9510) at malloc.c:3124
#6 0x00005555560cf2cb in AlignedBuffer<float*>::resize(unsigned long, int) (this=0x7fffcc017408, size=810, structSize=0)
at /home/danny/programs/code-art/rtengine/alignedbuffer.h:109
#7 0x00005555560cf058 in rtengine::PlanarPtr<float>::resize(unsigned long) (this=0x7fffcc017408, newSize=810)
at /home/danny/programs/code-art/rtengine/iimage.h:157
#8 0x00005555560ce788 in rtengine::PlanarRGBData<float>::allocate(int, int) (this=0x7fffcc0173b8, W=1155, H=810)
at /home/danny/programs/code-art/rtengine/iimage.h:690
#9 0x000055555609171e in rtengine::Crop::setCropSizes(int, int, int, int, int, bool) (this=0x555559eee000, rcx=1598, rcy=3469, rcw=1091, rch=746, skip=1, internal=true) at /home/danny/programs/code-art/rtengine/dcrop.cc:608
#10 0x000055555608ecfa in rtengine::Crop::update(int) (this=0x555559eee000, todo=528383)
at /home/danny/programs/code-art/rtengine/dcrop.cc:160
#11 0x0000555556091c29 in rtengine::Crop::fullUpdate() (this=0x555559eee000) at /home/danny/programs/code-art/rtengine/dcrop.cc:708
#12 0x0000555555c50f7c in sigc::bound_mem_functor0<void, rtengine::DetailedCrop>::operator()() const (this=0x55555a1d8ba8)
at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
#13 0x0000555555c50e5a in sigc::adaptor_functor<sigc::bound_mem_functor0<void, rtengine::DetailedCrop> >::operator()() const (this=0x55555a1d8ba0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
#14 0x0000555555c50c0c in sigc::internal::slot_call0<sigc::bound_mem_functor0<void, rtengine::DetailedCrop>, void>::call_it(sigc::internal::slot_rep*) (rep=0x55555a1d8b70) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:114
#15 0x00007ffff5a30f7d in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#16 0x00007ffff68c9175 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff25376db in start_thread (arg=0x7fffdc971700) at pthread_create.c:463
#18 0x00007ffff226088f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

‌

‌

[agriggio]

thanks for the detailed information!

[agriggio]

I just pushed a changeset that makes the problem go away. I’m still not 100% sure why though, so I’m leaving this open until we get more confident that indeed the bug is fixed. I tried various memory checking options (including the painfully slow valgrind) but none of them were reporting anything strange until the crash happened. It’s also quite strange that I could reproduce only when starting from a specific zoom level (12%), just zooming in a little bit to 15% before going to 100% made the problem go away. I’m still scratching my head…but I hope the new changeset works.

[Danny Heijl]

I'll test it tomorrow on Linux, thanks for looking into it. If I can still cause a crash I might try to compile with sanitizer options but I have done this only a couple of times before on small projects…

[Danny Heijl]

I tested with the latest source (Commit description: 1.3-4-g70ab3fa5e) on Linux and can no longer reproduce.

Thanks!

[Danny Heijl]

I can no longer reproduce it on Windows either using the latest generic nightly build from https://keybase.pub/gaaned92/ART-W64NightlyBuilds/ (ART_master_1.3-4-g70ab3fa5e_W64_generic_200503.7z).

You were right about the zoom level: in my setup the default view is at 12 %, both on Linux and Windows.

Thanks again!