Hi Alberto @agriggio
I’m running Fedora 39 Gnome or XFCE. After recent updates to the OS ART started freezing when I try to load an image file from Sony A7IV. The freeze usually happens at about 90% of loading done according to the progress control. I build ART from latest source code in the master branch. I debugged the freeze, it happens somewhere in the code that reads Exif info. Loading files from Nikon Z6 works fine. Loading Sony files on FreeBSD also works. Darktable and Rawtherapee do not have this issue. So it looks the failure is related only to ART, Sony files and latest Fedora updates. I’d be happy to provide all the details that I can.
Hi,
Can you run a debugging version under gdb and print a backtrace after stopping the program when it freezes? That would be the ideal feedback. If that’s not possible:
-
Are you using exiftool to get additional metadata? What happens if you disable it (just set the exiftool path to empty in preferences)?
-
Does it also happen with the official binary?
Thanks
1 Like
Hi Alberto,
Here is some info from my debugging:
$ ps axl|grep ART
0 1000 13386 3815 20 0 10100156 1457384 pipe_r Sl ? 1:01 /usr/local/bin/ART
1 1000 13816 13386 20 0 10100156 1288548 futex_ S ? 0:00 /usr/local/bin/ART
Child process 13816:
futex_wait (private=0, expected=9, futex_word=0x27090b0) at ../sysdeps/nptl/futex-internal.h:146
146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) list
141 a futex_wait call when synchronizing similar to Dekker synchronization.
142 However, we make no such guarantee here. */
143 static __always_inline int
144 futex_wait (unsigned int *futex_word, unsigned int expected, int private)
145 {
146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
147 switch (err)
148 {
149 case 0:
150 case -EAGAIN:
Parent process 13386:
0x00007f58b192640a in __GI___libc_read (nbytes=1, buf=0x7fff45825adf, fd=16) at ../sysdeps/unix/sysv/linux/read.c:26
Downloading source file /usr/src/debug/glibc-2.38-17.fc39.x86_64/io/../sysdeps/unix/sysv/linux/read.c
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) list
21
22 /* Read NBYTES into BUF from FD. Return the number read or -1. */
23 ssize_t
24 __libc_read (int fd, void *buf, size_t nbytes)
25 {
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
27 }
28 libc_hidden_def (__libc_read)
29
30 libc_hidden_def (__read)
(gdb) bt
#0 0x00007f58b192640a in __GI___libc_read (nbytes=1, buf=0x7fff45825adf, fd=16) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI___libc_read (fd=16, buf=0x7fff45825adf, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x0000000000bf720e in rtengine::subprocess::SubprocessInfo::read() ()
#3 0x0000000000bcb75d in rtengine::Exiftool::exec(std::vector<Glib::ustring, std::allocator<Glib::ustring> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) ()
#4 0x0000000000bc4f1c in rtengine::Exiv2Metadata::getExiftoolMakernotes[abi:cxx11](Glib::ustring const&) ()
#5 0x0000000000bc6d89 in rtengine::Exiv2Metadata::getMakernotes[abi:cxx11]() const ()
#6 0x0000000000c069b3 in rtengine::ExifLensCorrection::ExifLensCorrection(rtengine::FramesMetaData const*, int, int, rtengine::procparams::CoarseTransformParams const&, int) ()
#7 0x0000000000c08d8f in rtengine::ExifLensCorrection::ok(rtengine::FramesMetaData const*) ()
#8 0x00000000007923fe in LensProfilePanel::setRawMeta(bool, rtengine::FramesMetaData const*) ()
#9 0x00000000008b6875 in ToolPanelCoordinator::initImage(rtengine::StagedImageProcessor*, bool) ()
#10 0x0000000000674336 in EditorPanel::open(Thumbnail*, rtengine::InitialImage*) ()
#11 0x00000000006f25b0 in FilePanel::imageLoaded(Thumbnail*, ProgressConnector<rtengine::InitialImage*>*) ()
#12 0x00000000006f3d9b in ProgressConnector<rtengine::InitialImage*>::emitEndSignalUI(void*) ()
#13 0x00007f58b3bc0c7d in gdk_threads_dispatch (data=data@entry=0x7f55b6c3e900) at ../gdk/gdk.c:769
#14 0x00007f58b393678d in g_idle_dispatch (source=0x7f5830064ba0, callback=0x7f58b3bc0c50 <gdk_threads_dispatch>, user_data=0x7f55b6c3e900) at ../glib/gmain.c:6282
#15 0x00007f58b3939e5c in g_main_dispatch (context=0x2b75b20) at ../glib/gmain.c:3476
#16 g_main_context_dispatch_unlocked (context=0x2b75b20) at ../glib/gmain.c:4284
#17 0x00007f58b3994f18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x2b75b20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349
#18 0x00007f58b3937ad3 in g_main_context_iteration (context=context@entry=0x2b75b20, may_block=may_block@entry=1) at ../glib/gmain.c:4414
#19 0x00007f58b3dda92d in g_application_run (application=0x2d1b3f0, argc=<optimized out>, argv=0x7fff45826a60) at ../gio/gapplication.c:2577
#20 0x00000000005add91 in main ()-
I do not use exiftool. When I emptied the Exiftool command field in GUI nothing changed - ART froze again.
-
Where do I get the official binary? I always build ART from source code since Fedora does not have its package in their repos.
Let me know if I can provide anything else.
Thank you,
Andrew
Hi,
did you restart ART before trying? The backtrace shows that it hangs waiting for exiftool output as suspected.
from https://bitbucket.org/agriggio/art/downloads/, look for the linux64 archives (just uncompress and run ART)
1 Like
Hi Alberto,
Yes, I restarted ART many times trying different combinations. With exiftool disabled in GUI I got this backtrace:
(gdb) bt
#0 0x00007f62e3b2640a in __GI___libc_read (nbytes=1, buf=0x7ffe5a68570f, fd=16) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI___libc_read (fd=16, buf=0x7ffe5a68570f, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x0000000000bf72ae in rtengine::subprocess::SubprocessInfo::read() ()
#3 0x0000000000bcb7fd in rtengine::Exiftool::exec(std::vector<Glib::ustring, std::allocator<Glib::ustring> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) ()
#4 0x0000000000bc4fbc in rtengine::Exiv2Metadata::getExiftoolMakernotes[abi:cxx11](Glib::ustring const&) ()
#5 0x0000000000bc6e29 in rtengine::Exiv2Metadata::getMakernotes[abi:cxx11]() const ()
#6 0x0000000000c06a53 in rtengine::ExifLensCorrection::ExifLensCorrection(rtengine::FramesMetaData const*, int, int, rtengine::procparams::CoarseTransformParams const&, int) ()
#7 0x0000000000c08e2f in rtengine::ExifLensCorrection::ok(rtengine::FramesMetaData const*) ()
#8 0x00000000007923fe in LensProfilePanel::setRawMeta(bool, rtengine::FramesMetaData const*) ()
#9 0x00000000008b6875 in ToolPanelCoordinator::initImage(rtengine::StagedImageProcessor*, bool) ()
#10 0x0000000000674336 in EditorPanel::open(Thumbnail*, rtengine::InitialImage*) ()
#11 0x00000000006f25b0 in FilePanel::imageLoaded(Thumbnail*, ProgressConnector<rtengine::InitialImage*>*) ()
#12 0x00000000006f3d9b in ProgressConnector<rtengine::InitialImage*>::emitEndSignalUI(void*) ()
#13 0x00007f62e5e54c7d in gdk_threads_dispatch (data=data@entry=0x7f624c06e4c0) at ../gdk/gdk.c:769
#14 0x00007f62e5bf878d in g_idle_dispatch (source=0x7f624c088640, callback=0x7f62e5e54c50 <gdk_threads_dispatch>, user_data=0x7f624c06e4c0) at ../glib/gmain.c:6282
#15 0x00007f62e5bfbe5c in g_main_dispatch (context=0x1d97f40) at ../glib/gmain.c:3476
#16 g_main_context_dispatch_unlocked (context=0x1d97f40) at ../glib/gmain.c:4284
#17 0x00007f62e5c56f18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x1d97f40, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349
#18 0x00007f62e5bf9ad3 in g_main_context_iteration (context=context@entry=0x1d97f40, may_block=may_block@entry=1) at ../glib/gmain.c:4414
#19 0x00007f62e600492d in g_application_run (application=0x1f38cd0, argc=<optimized out>, argv=0x7ffe5a686690) at ../gio/gapplication.c:2577
#20 0x00000000005add91 in main ()I tried the official build - the same issue.
Thanks,
Andrew
Hi Alberto,
It seems I found a brute-force workaround. If I disable
bool exec(const std::vector<Glib::ustring> &argv, std::string *out, std::string *err)in
rtengine/metadata.cc like this
216 bool exec(const std::vector<Glib::ustring> &argv, std::string *out, std::string *err)
217 {
218 return false;
219 #if 0
220 bool ok = true;
...then the freeze is gone and I can load Sony images and edit them.
Looking at this method it seems it tries to execute an external command. In my own code at work I used standard pipe and related functions that work quite reliably. Though I only tested only on Linux.
If you have any ideas how I can try to fix and test the method please let me know.
Thanks,
Andrew
Well, I am using standard pipe and related functions, just a bit less directly. Anyway, I pushed a change that explicitly checks for an empty setting for exiftool in preferences and avoids going through that part of the code completely. If you could test that and let me know if it works (after setting “Exiftool command” in “Preferences → Image processing” to empty), that would be great.
Then, I will try to get a VM of Fedora 39 and see what is going on…
Thanks
1 Like
Also, can you share one of the problematic pictures? I tested here on a fedora VM and everything seems to work for me…
Hi Alberto,
Got your changes, rebuilt and viola - the freeze is gone.
Thanks a lot,
Andrew
I checked my Fedora installation. I do not have ‘exiftool’ command, but have ‘exif’. When I changed exiftool to exif in GUI ART stopped freezing. Maybe there should be a check if the command provided in GUI exists or something?
Well, I thought I had reasonable error checking in place (I did test with non-existing executables and didn’t get problems) but maybe I was unknowingly relying on some implementation-specific behaviour. I will try to revisit
1 Like
Please let me know if I can be of any help. I have a lot of experience with C++ and Linux, but more on the backend and not GUI. I really like ART and this is my go-to program to process raw files. Thank you very much for creating and improving it. Grazie mille! 
Hi,
Thanks for the offer! Can you open an issue on bitbucket so we can continue the discussion there?
@tankist02 I have pushed a tentative fix for the freeze. Would you be able to test again by setting exiftool to a non-existing file in the preferences and verifying that the freeze is indeed gone?
Thanks in advance!
@agriggio Got new changes, rebuilt, the freeze is gone now. I tried all combinations for Exiftool command to extract makernotes: empty, existing, non-existing and related Use exiftool checkbox on/off.
Created a new issue #320 with some comments, maybe it should be closed now
Great, thanks for testing!