Denoise(profiled) Crashes 3.4

Software darktable
1

I have had 2 crashes in the last 30 mins on separate images whilst using the denoise(profiled) module.
I was tweaking the ‘search radius’ when bang!

System is:
Dt 3.4 released version
Windows 10
‘modern’ workflow

I wasn’t doing anything dramatic or aggressive.
A normal kind of exposure, filmic, contrast equaliser, colour balance, local contrast, denoise sort of edit. (something I have done 100 times before).

Again tricky to isolate as pretty random.

Anybody else have any issues like this in the new 3.4?
I have looked through the forums but haven’t seen anything else about this, there were no previous issues in 3.2

Backtraces are here:

Error occurred on Monday, January 4, 2021 at 14:18:46.

darktable.exe caused an Access Violation at location 00000000636823C0 in module libdarktable.dll Reading from location 000000002E987000.

AddrPC Params
00000000636823C0 00000000063ACEB0 00007FF8ED152EF8 0000000000000000 libdarktable.dll!dt_module_load_modules
00007FF8D2B6DE30 0000000016320360 0000000000000000 0000000000000000 libgomp-1.dll!omp_in_final
00007FF8ED154F33 0000000011C5E2A0 0000000000000000 0000000016320360 libwinpthread-1.dll!pthread_create_wrapper
00007FF8F2DFAF5A 00007FF8F2E506D0 0000000016320360 0000000000000000 msvcrt.dll!_beginthreadex
00007FF8F2DFB02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex
00007FF8F1287034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF8F2F7D0D1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart

And

Error occurred on Monday, January 4, 2021 at 13:27:15.

darktable.exe caused an Access Violation at location 00000000636823C3 in module libdarktable.dll Reading from location 000000000B687000.

AddrPC Params
00000000636823C3 00000000065FD2B0 00000000065FD2B0 0000000000000004 libdarktable.dll!dt_module_load_modules
00007FF8E8036DC9 00000000065FD470 0000000000000080 00000000044D9001 libgomp-1.dll!GOMP_parallel
0000000063683953 00000000580EAE60 000000001BA16080 00000000144D92F0 libdarktable.dll!nlmeans_denoise_sse2
0000000069049381 00000000065FD7A0 000000004D7BF080 00000000065FD5B8 libdenoiseprofile.dll!0x9381
00000000637B50B0 0000000000000000 FDA11EDE6753E4E2 00000000065FD718 libdarktable.dll!dt_masks_events_post_expose
00000000637B6BB2 0000000000000000 93EC7E43F89F5531 00000000065FF718 libdarktable.dll!dt_dev_pixelpipe_cache_get_weighted
*00000000637B6EED 0000000000000000 0000000000000000 00000000065FF718

(loads of the above )

00000000637BBB0F 00000000001E0000 0000000000000001 0000000000000018 libdarktable.dll!dt_dev_pixelpipe_process
000000006375936D 0000000000000000 000000000071F8D0 000000005C593768 libdarktable.dll!dt_dev_process_image_job
00000000636C15E1 0000000000000000 0000000000000018 000000005C593768 libdarktable.dll!dt_control_write_sidecar_files
00000000636B9D1D 000000000070E4C0 0000000000000000 0000000000000000 libdarktable.dll!dt_control_crawler_show_image_list
00007FF8ED154F33 0000000003C8A7A0 0000000000000000 000000000070E4C0 libwinpthread-1.dll!pthread_create_wrapper
00007FF8F2DFAF5A 00007FF8F2E506D0 000000000070E4C0 0000000000000000 msvcrt.dll!_beginthreadex
00007FF8F2DFB02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex
00007FF8F1287034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF8F2F7D0D1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart

2

Just did it again, pushed the ‘search radius’ up to ‘20’ and DT barfs.
Its an ISO800 image so just trying to improve the painterly look you get by improving the denoise a bit.
From the backtrace seems a threading issue

Backtrace:

darktable.exe caused an Access Violation at location 00000000636823C0 in module libdarktable.dll Reading from location 0000000041C81000.

AddrPC Params
00000000636823C0 000000000636CEB0 00007FF8EDE82EF8 0000000000000000 libdarktable.dll!dt_module_load_modules
00007FF8E7EDDE30 00000000149F6600 0000000000000000 0000000000000000 libgomp-1.dll!omp_in_final
00007FF8EDE84F33 000000000F7D53D0 0000000000000000 00000000149F6600 libwinpthread-1.dll!pthread_create_wrapper
00007FF8F2DFAF5A 00007FF8F2E506D0 00000000149F6600 0000000000000000 msvcrt.dll!_beginthreadex
00007FF8F2DFB02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex
00007FF8F1287034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FF8F2F7D0D1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart

3

A bit more info, it seems to happen if you are zoomed into 100% or once you have tweaked the ‘search radius’ and then zoom in
I’m on Intel i3-4160, 64 bit but only 4Gb of RAM
Anybody else seeing this?

4

Having only 4GB of ram might be a problem in your case.

5

I did a quick test on 3.5.0+409 and I didn’t have any issues. I zoomed to 100%, selected Denoise (profiled) > non-local means and increased the search radius to 22. It took some time to denoise the image even with GPU, but no crash. I also managed to zoom in to 135%; the only issue was the time it took.

I’m on Win10, but I have 32M RAM.

6

Must be a special version of Win10, which works with only 32M RAM :wink:

1 Like
7

I agree 4Gb is not much but I never experienced this on 3.2.
Even when I was learning DT, pushing and pulling sliders all over the place to see what they did, I never had a single crash.
In fact I have never had a crash in 2 years of using DT and was frankly very impressed with its stability

8

If I just open an image with default exposure,filmic etc then I also don’t seem to have a problem.

It appears to be an issue once I have finished all the edits (couple of exposure, local contrast,colour balance etc) and then apply denoise at the end (which is my usual workflow)

Maybe its just the amount of stuff that’s gone on before and maybe now 4Gb RAM is really not enough anymore which I guess was always going to happen at some point :frowning_face:

If it continues to be an issue I’ll just change the way I do things and get denoising done first, turn it off, continue with edits and then turn it on again just before export and DON’T zoom.
I just thought it was worth reporting in case it was a genuine issue or if other people were experiencing the same

9

Having not enough RAM still should not crash the program, right?

1 Like
10

I’m also on W10, 9 year old machine, 12 GB RAM. I could move the search radius slider to 30 and back to default, moving other sliders, changing to auto wavelet etc. without a crash.

11

Hello

Just tried myself :slight_smile:

Windows 10 - darktable 3.4 (8 gb RAM)
No crash whatosever while moving the sliders of the Noise (profiled) module.
Actually, darktable is quite stable even on my 5 years old laptop…

12

It certainly can. Album 4GB is the total system ram. Windows is probably eating about 1GB, along with whatever else is open at the time.

1 Like
13

If you rename your appdata folder and the xmp file (so, start from scratch), does it still happen?

14

Hmm, not sure because it appears after quite a lot of edits, if I set to scratch then I lose the edits (if I understand correctly) and on new files ‘from scratch’ I don’t have an issue.
For example if I import a new image with just the ‘modern’ default (e.g filmic, exposure, color calibration) I don’t have a problem with denoise.
I can whack the search radius to 30, zoom in, whack the slider down again, zoom out, zoom in etc etc and all is good
It appears after a bit of editing using other modules and masks etc so some other editing either creates a bit of instability or running out of resources or its just a Monday!?!!

If anyone is interested I can post a bit of the XMP file that causes the issue

15

That’s what I suggested, either start a new edit from scratch as well as darktable itself.
Just in case.

16

Okay while I’m trying that there is something else.
Does it matter if the images that cause problems were previously imported in 3.2?
They had not been edited but did contain some active modules e.g filmic etc
I then discarded the history on these in 3.4 and started editing from there

17

If it appears after some edits and never on a fresh Darktable startup, then it can be a memory leak (even a small one).
And that could be reported.

18

Did that.

Started from scratch and edited a file - no problem (which is what I expected as I haven’t had issues with ‘new’ files just previously edited ones)

Went back to original set up, opened the problem file - no problem anymore - uuurrrgh - one of those things? A gentle memory leak as Olivier suggested? Windows update? Who knows

I have got to do a load more editing tomorrow so I’ll see what happens

Thanks for all the replies and help.

19

I think I am missing something here. If the system cannot allocate enough ram for dt, dt just crashes? No out-of-memory soft fail, but a hard crash?

20

Memory management on windows is not great. In theory the system should write other data to the windows page file (equivalent to the Linux swap), but if the chunk is too big, as it can be with image processing, or the system is too slow, then yes, a hard crash as the application is trying to use memory it doesn’t have.

The darktable recommendation for ram is at least 8GB for this reason.

1 Like