RT 5.4 on Windows 8.1 x64 crashes while in editor

[tsi12]

Branch: 5.4 Release Type: Stable (recommended) Commit: a5e8eb9c8 Build Type: release Processor: generic x86 Gtkmm Version: V3.22.0 Compiler: gcc 7.3.0 Build Flags: -m64 -mwin32 -mthreads -Wno-aggressive-loop-optimizations -std=c++11 -mtune=generic -Werror=unused-label -fopenmp -Werror=unknown-pragmas -Wall -Wno-unused-result -Wno-deprecated-declarations -DNDEBUG -O3 Link Flags: -m64 -mthreads -static-libgcc -mtune=generic -s -O3 -fno-use-linker-plugin OpenMP: Yes, Mmap: Yes

Build from gaaned92

System: Windows 8.1 x64 SL CPU: Intel Core I7 at 2.6 GHz RAM: 16 GB

Build from: http://rawtherapee.com/releases_head/windows/RawTherapee_5.4_WinVista_64.zip

RT shuts down suddenly while develop in editor tab.

log1.txt log2.txt

Perhaps, logs aren't complete, because GDB crashes.

[Thanatomanic]

Do you know if it crashes while performing a specific operation? And the follow up question: is it reproducible?

[Floessie]

@Hombre57 I'm looking at this:

Thread 1 (Thread 3060.0xb88):
#0  CropWindow::pointerMoved (this=this@entry=0x1310a380, bstate=<optimized out>, x=<optimized out>, y=<optimized out>) at D:/RAWTHERAPEE/RTSOURCE/rawtherapee/rtgui/cropwindow.cc:1052
        vx = 1015
        pix = 0x359ed9f5 <error: Cannot access memory at address 0x359ed9f5>
        gval = 52
        vy = 804
        imwidth = 1180
        imheight = 787
        rval = 0
        bval = 0
        mx = 3958
        my = 3135
        editSubscriber = <optimized out>
        oRA = <optimized out>

The relevant line is here.

One reason it segfaults in this line could be a bad cropHandler.cropPixbuftrue pointer. There might be two problems with cropHandler.cropPixbuftrue:

1. The validity isn't checked, but cropHandler.cropPixbuf is checked for, which should also cover cropHandler.cropPixbuftrue.
2. Both cropHandler.cropPixbuf and cropHandler.cropPixbuftrue are set under cropHandler.cimg.lock(), but here the mutex is acquired after the cropHandler.cropPixbuf check.

Another reason could be one of the parameters that add up to pix is out of bounds.

Also note that pix lies on an odd address.

Maybe you can make sense of it.

HTH, Flössie

[tsi12]

Thanatomanic First log: it happened during contrast by details (details tab) adjustment. Second log - i don't remember. Generally, it happens more frequently to "fast" build, than "debug" build.

[Hombre57]

@Floessie I worked on amaze_vng4 today, it's too late now. I'll have a look tomorrow.

[Hombre57]

@Floessie What's the problem of addressing an odd value if we look for a particular pixel ?

For the cropHandler.cimg.lock(), that's true, it should be placed before the cropHandler.cropPixbuf check. I also saw a mix-up between cropHandler.cropPixbuftrue and cropHandler.cropPixbuf on line 1048-1050. I'll create a new branch tomorrow.

[Floessie]

@Hombre57

What's the problem of addressing an odd value if we look for a particular pixel ?

I hope nothing is wrong with that. It just struck me.

[Hombre57]

@tsi12 Could you review/test branch issue4580 ? It doesn't crash here so it's a blind bugfix attempt

[tsi12]

@Hombre57 Can you explain briefly what should i do? Thanks.

[Hombre57]

@tsi12 Reviewing was for @Floessie, I forgot to remove that from my comment. Could you simply build this new branch (if you can build yourself of course, otherwise I'll send you a binary) and tell if it still crash in the same conditions.

[heckflosse]

@tsi12

git pull git checkout issue4580 make install then test the build

[tsi12]

@Hombre57 Send me binary, pls.

[Hombre57]

@tsi12 You'll find a release and debug version here.

Test the release version first, as it's the fastest and more crash prone if related to mutex. If it still crash, it would be great if you could provide a full stack trace using gdb and the debug version.

[tsi12]

@Hombre57 This release version works, but still crashes. It seems less stable than a5e8eb9. Debug version crashes after running, during scanning the folder.

log0.txt log1.txt log2.txt log3.txt

[Hombre57]

@tsi12 The function present in the four crashlog above is rtengine::LFDatabase::findLens, so I'd like to explore the lensfun option. @Floessie @agriggio : is lensfun threadsafe ?

[Floessie]

@Hombre57 Darktable thinks, it's not. Thread-safety is only mentioned for lfModifier, so I guess, everything else isn't.

HTH, Flössie

[fsenore]

I am the author of bug report #4588 that was closed as a duplicate of this report.

I don't know if the problem is caused by using a Micro Four-Thirds camera that uses heavy lens correction, but when I change the zoom level RT crashes very often. This forces me to continuously go from the editor to the file browser and back again just to save the .pp3 file: at least when RT crashes I do not lose my work. Unfortunately this makes the program barely usable: are there plans to fix this problem?

Thanks in advance.

[Hombre57]

@fsenore Ctrl+S will save the pp3 of the edited image at the selected step in the History.

I'll try to blindly fix the crash tonight. Can you build, test and report back ?

[fsenore]

Thank you for the Ctrl+S tip: it will save me a lot of time.

I never built RT but I am a software developer and I can try.

[Beep6581]

There is also ctrl+shift+s which auto-saves a PP3 in the designated place.

[fsenore]

@Hombre57 I have successfully built RawTherapee, so now I can test your fix as soon as it is available.

@Beep6581 Thank you for the ctrl+shift+s suggestion: it is what I was looking for.

[Hombre57]

@fsenore Great ! So please test the lensfun-mutex branch. I've added some mutex (excepted for thread safe functions), but since I don't use lens fun, never tried the patch.

[fsenore]

Since I had already built the dev branch I merged the lensfun-mutex branch and I built RT.

Now I have a problem: I run RT from the MSYS2 shell and it looks like it cannot find the lensfun database. In the "Profiled Lens Correction" section the "Auto-matched correction parameters" choice is disabled and I can see that distortion is not corrected. The lensfun database is stored in the "C:\msys64\mingw64\share\lensfun\version_2" folder and maybe the executable cannot find it. Do you have any suggestion?

[Hombre57]

I'd suggest to start RT outside of MSYS, though I'm not sure it will make a difference. When building a Debug binary, you'll probably use a dedicated cache and settings folder, and you'll have to set the path again.

There's no GUI for this options parameter, but look for the [Lensfun] section, and set :

DBDirectory=C:\\msys64\\mingw64\\share\\lensfun\\version_2

[fsenore]

Sorry for the delay, I have been out of home for a couple of days. I set the DBDirectory line in the options file as you suggested and now RT has a segmentation fault at startup. I also copied Lensfun in the expected location, just to check, and I still get the segmentation fault. If I remove the reference to lensfun the program starts correctly, but obviously lensfun is not available.

P.S. may you explain me how to highlight text like in "[Lensfun]" in your last post? Thank you.

[fsenore]

Ok, it was a problem with the latest version of lensfun. I have finally been able to compile your lensfun-mutex branch and I have tested it on a few images: it is working without crashes so it looks like the problem is fixed. I will keep using it in the next days and I will report problems here, if I will find any of them.

Thank you for your help.

[Hombre57]

@fsenore Are you saying that there's no crash with the dev branch too now ? Or should I still commit the lensfun-mutex branch (once you validate it) ?

[fsenore]

I tested your changes, since I compiled the lensfun-mutex branch. So I believe that you should still commit that branch.

[fsenore]

@Hombre57 I have tested the program and it looks more stable, but today I had some crashes. The program crashes when I am looking at a part of the image and I click the button to show the whole image on screen. The images that I was editing are taken with a Nikkor 50mm mounted on my Panasonic GX-7 with an adapter, so in the raw file there are no info about the lens. Profiled lens correction is thus set to None. I don't know how RT works, but I'd expect that lensfun is not used in this situation, since there are no info about the lens. I have no debug version of the program that I compiled so I run the debug version of V5.4 and I got an error log that I have attached to this message. I hope that i can be useful, even if it looks the same as previous ones. rt-log3.txt

[Hombre57]

@fsenore I've committed a patch because there was something odd in the pix pointer, not related to lensfun, but might be the reason of your crash.

I've merged the lensfun-mutex branch into dev and will delete that branch in few days (or when back from holidays).

[Hombre57]

@tsi12 @fsenore Please try the issue4580 branch now, it adds more bugfix (hopefully).

[fsenore]

@Hombre57 Yesterday I built the issue4580 branch and I still had a crash after some work on an image taken with the same lens, therefore unsupported by lensfun. So I built a debug version and I used it for some time but the crash did not happen any more. Today I started the program, I opened an image, I zoomed it in a little then I pressed the button to show the full image and I had an immediate crash. I have attached the log and I hope that it can be useful. The log is created with a debug version of the issue4580 branch. rt-log4.txt

[Hombre57]

@fsenore Please pull and test again. This is the last patch I can think of while shooting in the dark, as it doesn't crash here. I really don't think it's related to lensfun or metadata, but rather a race condition on your system with this image size.

[fsenore]

@Hombre57 Sorry for the delay, I have been out of home for some days. I have pulled the source code and I built RawTherapee. In the next days I will test it and I will report if it works.

Again, thank you for your help.

[fsenore]

@Hombre57 I have tested the program for some time and I only had one single crash: it's a large improvement and now RT is very usable for me. I think that your changes can be merged with the main branch. Thank you for you help.