Resulting JPG file is locked after Save As, Linux build 5.10-194

[kaesa]

Short description
When I "export", meaning when I select "Save As" from the bottom buttons, the resulting .jpg file is locked in a same way as in the issue #7045. I didn't think much about this small problem before, but now I wonder if there is an accidental file descriptor leakage in this case as well. In other words, from my memory, this might not be a very new issue.

• So far seems to affect only 8-bit JPG type.
• PNG 8-bit files are not affected.
• PNG 32-bit files are not affected.
• TIFF 8-bit files are not affected.
• TIFF 16-bit files are not affected.
• TIFF 32-bit files are not affected.

Steps to reproduce

Prerequisite:
The working directory must be an SMB share or something with similar properties. The problem does not trigger from local drive.

Procedure:

1. Open file for editing. Source file type doesn't seem to matter.
2. Click on Save As from the bottom buttons.
3. Select .jpg as file type.
4. Try to rename the resulting file in the terminal.

Expected behavior
File should be workable, after RawTherapee is finished with the file.

Additional information

Details

Version: 5.10-194-g95f85d50f
Branch: dev
Commit: 95f85d5
Commit date: 2024-04-24
Compiler: cc 13.2.1
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.24.8
Lensfun: V0.3.4.0
Build type: Release
Build flags: -std=c++11 -ffp-contract=off -Werror=unused-label -Werror=delete-incomplete -fno-math-errno -Wno-attributes -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -Wunused-macros -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags:
OpenMP support: ON
MMAP support: ON
Build OS: Linux 5.15.154-1-MANJARO x86_64
Build date: Thu, 25 Apr 2024 12:30:25 +0000 UTC
Build epoch: 1714048225
Build UUID: a2f87bcb-cf54-4487-b9df-d50657285d60

[Lawrence37]

Unlike #7045, the file is closed after it is done using it.

[kaesa]

I have new information on this.

I did a new debug build with the latest dev version 5.10-208 and ran it on valgrind. It seems like the issue of the locked file is related to the thumbnails. I did some more testing to make sure to narrow down the problem. Here are the added notes:

• The problem is reproducible if I open the RawTherapee in file browser and then open the source file to Save As jpeg.
• The issue is not reproducible if I open the file directly with RawTherapee from file manager.
• The issue still seems to exist only for the jpg files.
• Opening directories with jpg files and/or opening jpg file from such directory doesn't have issues.
• So far reproducible only after Save As has been used to generate a new jpg file.

I think this is the relevant part from the Valgrind result:

Details

==5290== at 0x7280705: open (in /usr/lib/libc.so.6)
==5290== by 0x720393E: _IO_file_open (in /usr/lib/libc.so.6)
==5290== by 0x7203AC4: _IO_file_fopen (in /usr/lib/libc.so.6)
==5290== by 0x71F7D5A: ??? (in /usr/lib/libc.so.6)
==5290== by 0xB420EA: rtengine::ImageIO::loadJPEG(Glib::ustring const&) (in /usr/local/bin/rawtherapee)
==5290== by 0xE871B0: rtengine::StdImageSource::load(Glib::ustring const&) (in /usr/local/bin/rawtherapee)
==5290== by 0xE5C0F8: rtengine::Thumbnail::loadFromImage(Glib::ustring const&, int&, int&, int, double, rtengine::StandardObserver, bool) (in /usr/local/bin/rawtherapee)
==5290== by 0x9B0A8F: Thumbnail::_generateThumbnailImage() (in /usr/local/bin/rawtherapee)
==5290== by 0x9B1CE5: Thumbnail::Thumbnail(CacheManager*, Glib::ustring const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) (in /usr/local/bin/rawtherapee)
==5290== by 0x4A824A: CacheManager::getEntry(Glib::ustring const&) (in /usr/local/bin/rawtherapee)
==5290== by 0x91734F: PreviewLoader::Impl::processNextJob() (in /usr/local/bin/rawtherapee)
==5290== by 0x5E04F41: (anonymous namespace)::call_thread_entry_slot(void*, void*) (slot.h:540)

[kaesa]

I tested and turning the file descriptor at

RawTherapee/rtengine/imageio.cc

Line 483 in e316e87

FILE *file = g_fopen(fname.c_str (), "rb");

into a smart pointer following the #7056 commit solved the issue in this report. I don't know if it hides other bugs though.

[Lawrence37]

That code is in the JPEG file reading function. Did you save the JPEG in the directory that is open in the RawTherapee file browser?

[kaesa]

That code is in the JPEG file reading function. Did you save the JPEG in the directory that is open in the RawTherapee file browser?

Yes. Right next to the source file.

I now tested creating a subdirectory for the open directory and when saved there, there was no locking issue. The option to show images recursively in subdirectories was not enabled. After enabling the recursive option, the locking happened in the subdirectory as well.

[Lawrence37]

Ok, it makes sense now why the freeze is happening.