Comment 13 for bug 1976189

Hey Joshua, no problem, thanks for your feedback! I'm not using this tool right now, but I'll definitely check it out! I'm happy to read you enjoy learning about all these things same as I do :)

Thank you for sharing the trace, are you getting into this error directly when starting the app or are you loading a file or one of the PoCs? I think I got the same error today directly at startup when I executed the binary from the build directory, but after running the install step, I no longer got the problem. I couldn't trigger the problem again afterwards, so I assume it was about some inconsistencies in the environment.

Let me share how I build the program from source for testing:

meson build -Db_sanitize=address,undefined -Dbuildtype=release -Dprefix=/usr
cd build
ninja
ninja install

Maybe you can try to clean your env, remove gthumb and gthumb-data and then do the same and check if the problem still occurs for you?

Today I also noticed that the image 20200704_174327.jpg still causes an overflow that goes unnoticed without sanitizer enabled, so I'll share it right now in case you also encounter this problem:

==79994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000a010d3 at pc 0x7f71c3158490 bp 0x7f71875f3a20 sp 0x7f71875f31c8
READ of size 5 at 0x602000a010d3 thread T30 (pool-gthumb)
    #0 0x7f71c315848f in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:790
    #1 0x7f71c2ec9fd0 in g_utf8_substring (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x84fd0)
    #2 0x55d04920bf73 in _g_utf8_has_prefix (/usr/bin/gthumb+0x5c3f73)
    #3 0x7f719f311621 in create_metadata(char const*, char const*, char const*, char const*, char const*, char const*) (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0x84621)
    #4 0x7f719f31c29d in exiv2_read_metadata(std::auto_ptr<Exiv2::Image>, _GFileInfo*, int) (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0x8f29d)
    #5 0x7f719f3310b6 in exiv2_read_metadata_from_file (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0xa40b6)
    #6 0x7f719f34ebcc in gth_metadata_provider_exiv2_read (/usr/lib/x86_64-linux-gnu/gthumb/extensions/libexiv2_tools.so+0xc1bcc)
    #7 0x55d04948615e in _g_query_metadata_async_thread (/usr/bin/gthumb+0x83e15e)
    #8 0x7f71c2d13c61 (/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xb5c61)
    #9 0x7f71c2ec1373 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7c373)
    #10 0x7f71c2ec0ad0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7bad0)
    #11 0x7f71c1497608 in start_thread /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477
    #12 0x7f71c13bc132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)

I did another bisect and found these two (unfortunately huge!) commits 62b059b5591baba80b46b17f1042a5065b43deaa, 7cad30b55c8c17fa03508c1f32db613fc9e2b198 after which the problem no longer occurs.
I tried to take the stack as reference and replaced the function _g_utf8_has_prefix with the updated one from 62b059b5591baba80b46b17f1042a5065b43deaa and it seems to solve the problem.

Hope we get this done together :)