Crash while loading Fuji XTrans files

[pi99y]

Hi, I get quite frequent crashes that seem to be caused by older pp3 files, but it's really hard to pinpoint the issue, since it's a bit "random"...

Tested on:

• OS: Windows 8.1 64bit, 8GB ram
• RT: RawTherapee_WinVista_64_Gtk3_Debug_4.2.730.zip Changeset: f5d5083be68f7cf487a688dcab37b91455fc9e6e
• Fuji X-Pro1 XTrans RAF files

I open up a folder with a at least a few images, try to load a file and it sometimes crashes. It can either crash while still in (or returning to) "file browser" view or already in the "editing view", but seems like it always crashes while either "loading", "demosaicing" or "processing" - not later on while editing (if i can get to that stage).

It seems not to be tied to specific image since it sometimes crashes on one file, some other time on another file, but nothing really consistant.

I tried to narrow it down, but I can only say that it appears that at least two things help while reproducing:

• thumbnails of images are not yet created (It's easier to reproduce if I clear the cache before opening RT) Since this mostly happens during the thumbnails are being generated it helps to have many images in the folder - so you have more time to reproduce it. This is probably also why I can't reproduce this with a single file (that crashed before).
• images have old pp3 files present (it doesn't happen if I create new pp3's with the current RT version, although the general "profile" I load has roughly the same preferences - since that's the one I always start with) PP3 files in this case say "AppVersion=4.1.80 Version=321".
• it could be raf/xtrans specific (can't test other)

Most of the time it crashed I get the debug report saying "pure virtual method called, terminate called without an active exception" but not always (sometimes there is no error message in the debug window)

Also note that the "failed to fetch network locations" error you see in the screenshot pops up every time I start RT and seems not to be related to this issue.

Screenshot: https://i.imgur.com/PMbtxiM.jpg PP3: http://filebin.net/tvof90mays (I'm not missing any files that are referred to in a profile, just the RT version is newer)

[heckflosse]

@pi99y It's related to xtrans files. I can reproduce it in Release build of master branch. It's not related to old pp3 files (at least the crash I get).

[sguyader]

I do not seem to get this kind of problems with xtrans files from my Fujifilm X-T1.

[heckflosse]

I can sometimes reproduce it with a X-Pro 2 dng file. Sometimes it crashes, sometimes I got black output when saving to tif (bit not when saving to jpg) and sometimes it works fine. Looking

[pi99y]

@heckflosse Great! I mean, great you can reproduce it. You're much likley to find the cause than me. Thanks for looking into it.

[heckflosse]

Unfortunately I can't reproduce it in debug build. I'll run it through valgrind

[pi99y]

For me it's also present (the crash) in: Version: 4.2.699, Changeset: 3c016c41e3654cf098947057383afa2158948a7a Version: 4.2.674, Changeset: 676a4441a12b30b401b9df49b976e32cba7c9b36 Version: 4.2.670, Changeset: 1a9121714a3a8e04d09ca0cf0f237345a732d962 Version: 4.2.539, Changeset: 6260b472a628e1d099c2b833e2e006c90a20e875 Version: 4.2.510, Changeset: 7ef35abb57ebd3654fc9e7b3b383821a7152eb87

EDIT: I can now CONFIRM that it also happens (but seems less frequent) with pp3s of current version (.730). However it never happened to me if I removed the pp3 altogether. So it might be still something with reading/applying pp3s.

EDIT: "backtrace" screenshot https://i.imgur.com/1GAusId.jpg

EDIT: whole gdb log http://filebin.net/ctjdqlr0j7

[pi99y]

Disabling film simulation in those pp3 files seems to "fix" it...

I "mass edited" the:

[Film Simulation] Enabled=true

to

[Film Simulation] Enabled=false

in the pp3 files and now I either cannot reproduce or it is at least much less frequent (no crash yet)... so my crash is somehow related to that...

[heckflosse]

I opened #3156 because I think the crashes I observed have a different reason than the crashes pi99y observed.

[pi99y]

I did a test:

I downloaded a PEF image and copied it 50 times, applied my usual default profile and then applied another bundled profile on top of that. I then set about 20 different film simulations across those 50 images. I closed RT and cleared cache. I ran RT again and tried to crash it, I couldn't.

Then I did the same test, but I uset a single FUJI Xtrans file (50 copies of it). Other steps were the same... I could crash it again.

So for now it looks it could be a combination of Xtrans & film-simulation...

[pi99y]

@heckflosse Sadly, @sguyader 's new RawTherapee_WinVista_64_Gtk3_Debug_4.2.764 Changeset: 5086c0dbb92b34c37a18e5d019c41ff755834057 didn't solve this.

Here are two new backtraces of this crash: http://filebin.net/ctjdqlr0j7/gdb2.txt and http://filebin.net/ctjdqlr0j7/gdb3.txt

Thanks.

[sguyader]

@pi99y Ingo's fix was pushed to the Master branch, so if you want to test it you should try my Master (4.2.677) build.

[pi99y]

Oh, cool, so there still is a chance! :) I'll report back.

[pi99y]

Unfortunately it's still the same (with Master branch: 4.2.677)... still crashes. New backtrace log: http://filebin.net/ctjdqlr0j7/gdb4.txt

[Karteileiche]

Hello!

any news about the bug? If required, i can provide raw files too which crash RT.

[heckflosse]

Please provide files :+1:

[Karteileiche]

The problem exists since i updated my XE2 to FW4.0.

I have uploaded 3 files at http://filebin.net/hv52p3oyjh . Different content but same parameters. If you need RAW with different settings please specify.

I use RT 4.2.0 with Linux Mint and with Windows 7 64bit (4.2.699, 64bit). Both quit when i want to open a file from the file manager to the edit window. The file manager itself shows all files with correct meta data.

[heckflosse]

@Karteileiche After solving the trouble with your zip (it contains a tar file with extension .RAF) I could open all three files without problems using rt 4.2.745 on Win7/64

[Karteileiche]

Sorry for the ZIP-problem.. i just used the "compress" option in Mint/Dolphin file manager.

I did not know that there is a newer version, it is not listed at http://rawtherapee.com/downloads. But i found the links at the discuss platform and tried. It seems to be fixed in that version.

Thanks for your Help.

[heckflosse]

@Karteileiche Ok, thank you for the report and the example files :+1:

[pi99y]

Sorry for the inactivity. I can still easily reproduce the crash (with the images I provided to @heckflosse) on the latest "master" RawTherapee version 4.2.752 b3f6f1c1b522df1b6effe04da1b69c2af354b690 But mainly on those files with old pp3s. Editing images without (or current) profiles seems totaly fine.

[heckflosse]

@pi99y I tried to reproduce the crashes with the images you provided. But all works fine here. If you have one image with the corresponding pp3 which allows to clearly reproduce the crash, please tell me.

[pi99y]

No, sorry, for me it seems it's the process of creating previews/thumbnails while trying to edit what seems to crash it. A specific SET of files. Sometimes one fine works fine, the other time it crashes...

ALSO: could it be that you can't reproduce it from my files since you don't have CLUTs at the right location (as referenced in my pp3s)? Previously I reported that it seems film simulation related...

[heckflosse]

@pi99y I don't remember. I'll try again

[candardo]

RAF files from my X-E2 firmware 4.0 crash RawTherapee on Linux (Debian sid, RT 4.2.something) and work on Windows (W10 RT 4.2.905). Having no problems with the latest (windows) version I expected this bug to closed and filed a bug to the Debian BTS asking for a new build.

Any updates on this issue?

[Karteileiche]

@candardo

you are right, the linux version lacks on this fix. i am also waiting for an update.

@heckflosse Beside the XE2 FW4.0 incompatibility, i experienced crashes several times when saving files during the edit process (saving directly form the edit window, not using the queue).

[Beep6581]

1. Trouble with a raw file? Always provide a sample raw file, use http://filebin.net/
2. Crash? http://rawpedia.rawtherapee.com/How_to_write_useful_bug_reports

[candardo]

Latest RT package downloaded from Debian Linux.

Example raw file: http://filebin.net/bgx5dbkn5c

Actions to reproduce bug: RT crashes when trying to edit files after previewing it with the File Browser tab so no PP3 file available.

console output:

leo@asbesto:~/Scaricati$ rawtherapee 
/home/leo/Scaricati/test/DSCF1468.RAF: Unexpected end of file
Segmentation fault

Download page (Debian Sid package amd64): https://packages.debian.org/sid/rawtherapee

It's not the latest version but I like to use Debian package when possible. Of course you're not supposed to fix an old version. I filed a bug against the Debian package asking to provide a newer build since I 4.2.905 on Windows works fine.

From settings|info:

Branch: default
Version: 4.2.0
Changeset: c81d9026d25c
Compiler: cc 5.3.1
Processor: undefined
System: Linux
Bit depth: 64 bits
Gtkmm: V2.24.4
Build type: Release
Build flags: -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -Wdate-time -D_FORTIFY_SOURCE=2   -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG
Link flags:  -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
OpenMP support: ON
MMAP support: ON

[Beep6581]

No crash here, DSCF1468.RAF opens fine and applying Auto-Levels works. Tested in gtk3 tip (4.2.942 56af7e88)

--update Ok, I see now that you reported a non-bug. No need to do that here as you can see it works fine in the latest version and we don't maintain Debian packages, or any packages. Instructions on our homepage in the Debian category will point you to the correct person, if any.

[candardo]

I was not reporting a bug here. I was looking for a relevant upstream bug to point the Debian maintainer to. It was not obvious at all that the problem stems from a particular camera firmware version.

I only asked why is this issue still open since it looks like it's fixed both on Windows and Linux with the latest version.

[Beep6581]

Closing as fixed.

[pi99y]

This (see my posts above) is NOT fixed, crashes consistently also with RawTherapee4.2.814 as it did with the previous builds.

[Beep6581]

@pi99y can you still reproduce the crash using the new Hald CLUT code from May 1? That means gtk3 version 4.2.967 or newer. If you don't compile yourself, keep an eye on this link, I hope @sguyader can provide a new build: https://discuss.pixls.us/t/new-windows-builds/615/198?u=morgan_hardwood

If you can still reproduce the crash using the new version, please provide sample raw file(s) with sample pp3(s) with which to reproduce, along with a new stack backtrace, then it will make sense to re-open this issue, or to open a new issue. If you do, please click on "Administration interface" in http://filebin.net/ and set the lifetime to 1 year so the uploads don't expire so quickly.

[pi99y]

OK, I'll wait for @sguyader 's new build or (if he won't be able to make one in a few days) I'll do it with the 32bit build.

Also are the newer debug builds now working OK? I remember (from IRC I think) something about (windows) backtraces not being ~descriptive enough - see the debate here #3231 Are the new builds now compiled with the correct "settings"? Since the debug builds are really slow for me I'd hate to "waste" the time if it's not helpfull.. Thanks

[Beep6581]

Debug builds are always descriptive. The -DWITH_SAN=thread option is something extra. @heckflosse @adamreichold do you think a build with the thread sanitizer would help?

[sguyader]

Ok I'll make new builds (it's going to take some time, I make the Windows builds in a Windows virtual machine which shares the machine resources with the host system, on an aging laptop...) Should I make only Gtk3 builds, or should I make builds from Master branch too? I'll try the -DWITH_SAN=thread option fro the Debug build, but last time I tried it didn't work.

[Beep6581]

Well, I will only upload gtk3 ones. As for the usefulness of sanitization of the debug build, @heckflosse @adamreichold and @Floessie should decide.

[heckflosse]

@Beep6581 @sguyader IIRC sanitizers still don't work with windows builds

[sguyader]

Here's a link to Gtk3 Release and Debug builds: http://filebin.net/jj9l7sgaij

[pi99y]

@sguyader Are these two new builds by any chance not compiled right? Now it crashes every time and the gdb log includes your username:

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4472.0xd90] 0x0000000000b60896 in LUT::operator at C:/msys64/home/sguyader/rtrepo-gtk3/rtengine/LUT.h:453 453 C:/msys64/home/sguyader/rtrepo-gtk3/rtengine/LUT.h: No such file or directory.

[Beep6581]

I uploaded those builds to the website. Would be good if someone else could confirm the problem so I take them down ASAP if they're faulty.

[Floessie]

@Beep6581 I wouldn't generally advocate sanitizers for the debug build: While debug builds are big and slow, instrumented builds are even bigger and slower. I've got no experience with TSan, but finding subtle races ("heisenbugs") sometimes is even impossible with debug builds, as they behave quite differently from release builds when it comes to timing issues. IMHO having backtraces is enough most of the times to catch them. But a sanitizer build to nail down a specific problem like this one would definitly help.

Now it crashes every time and the gdb log includes your username.

@pi99y That's normal. But a full backtrace is what's needed here. Especially the next frame, the caller who calls LUT<float>::operator[] with -nan, is of interest.

Would be good if someone else could confirm the problem so I take them down ASAP if they're faulty.

@Beep6581 Apart from the fact, that I'm not on Windows, I'll be offline this evening, sorry.

[heckflosse]

@Beep6581 I tested the Release build from @sguyader. I opened some RAF files. Can't confirm the crashes.

[pi99y]

@heckflosse Can you try reproducing the crash with a RAF that has an existing pp3 which uses film simulation please

meanwhile a full backtrace: http://filebin.net/egkvka7twv/rtcrash.txt

[Beep6581]

Great, the builds stay up.

@pi99y

If you can still reproduce the crash using the new version, please provide sample raw file(s) with sample pp3(s) with which to reproduce, along with a new stack backtrace, then it will make sense to re-open this issue, or to open a new issue. If you do, please click on "Administration interface" in http://filebin.net/ and set the lifetime to 1 year so the uploads don't expire so quickly.

The backtrace you pasted lacks the important part, see step 5 onwards: http://rawpedia.rawtherapee.com/How_to_write_useful_bug_reports#Step_by_step

Please supply the minimum number of sample raw(s) + PP3(s) needed to reproduce this. We can figure out the required Hald CLUT folder structure from the PP3(s), as long as you used the Hald CLUTs from the "RawTherapee Film Simulation Collection".

[sguyader]

I can reproduce it, I think, with the new build. It occasionally crashes with some files (it never crashes my files form my X-T1 though). I'll try to make backtraces.

[pi99y]

@Beep6581 The backtrace was done with all the steps but windows gdb has allways crashed for me after the "thread apply all bt full" which I guess was the reason for the "sanitation" version as noted in #3231 Please note that in #3231 @sguyader did provide one build with the added option (I'm guessing) which didn't crash the gdb (I have noted that in the thread)

I did use the "RawTherapee Film Simulation Collection".

I'll post the RAF files shortly here: http://filebin.net/egkvka7twv/RTtest.zip (This latest build crashes every time for me just by browsing to the directory with these 2 (above link) photos in it. I have also included the camera profiles I use in case that's the problem, but you'll need to manually adjust the path to profiles in the pp3 file).

[sguyader]

No my build wasn't sanitized, just as Ingo said thread sanitization fails on Windows (I saw it's supported only on Lunix 64 bits).

[heckflosse]

@sguyader Sebastien, I just found a buffer overrun. As you can reproduce the crash, can you try with this patch please?

[pi99y]

Now I have uploaded the files (in my previous post above). What else can I do?

[sguyader]

Ingo I'll try your patch. In the mean time, here's a backtrace of a crash, from an X-T1 file (source DPReviw), no previous pp3, starting from default processing profile, and just activating Film Simulation and loading a HALDClut:

http://pastebin.com/cdm1LYdJ

(I pasted the last lines in the console of gdb run followed by full bt)