Thank you, it works now.
ART pretty often (every fourth or fifth time) crashes on startup, I believe at the point when file browser should become visible. Both the regular and the libraw versions are affected. But I can’t get the debug to reproduce it. It feels like something prevents the debug to crash at this point… 
It even took only one try for this video. 
Of course, windows protocoll shows nothing. Is there anything else I could offer to help with this?
Thanks. This is likely a race condition somewhere in the UI code. I’ve been tried to track this down for a while, but so far with no luck. It doesn’t help that I can’t seem to reproduce it here unfortunately…
I see. Too bad it’s not possible to run debug at full speed.
You can try building in RelWithDebInfo mode and see if that gets you somewhere…
I’m just an ordinary end user, not building anything.
I’ll see if I can prepare a build for windows for you to test, if you want.
I would test it. In the end, it’s supposed to help you.
I made a rlewithdebinfo build : use art-debug.exe in
https://keybase.pub/gaaned92/ART-W64NightlyBuilds/ART_libraw_1.8.2-216-gb9fee6300_W64_generic_211104.7z
Version: 1.8.2-216-gb9fee6300
Branch: libraw
Commit: b9fee6300
Commit date: 2021-11-04
Compiler: cc 11.2.0
Processor: undefined
System: Windows
Bit depth: 64 bits
Gtkmm: V3.24.5
Lensfun: V0.3.95.0
Exiv2: V0.27.5.2
LCMS2: V2.12
LibRaw: V0.20.2
Build type: relwithdebinfo
Build flags: -m64 -mwin32 -msse2 -mfpmath=sse -mthreads -Wno-attributes -Wno-aggressive-loop-optimizations -Wno-parentheses -std=c++11 -fno-tree-loop-vectorize -Werror=unused-label -fno-math-errno -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O2 -ftree-vectorize -g
Link flags: -m64 -mthreads -static-libgcc -O2
OpenMP support: ON
Build OS: Windows
Build date: 2021-11-04T11:42:38Z
I can modify the different build flags. I made some trials but I get hangs without being able to get a BT
Thanks, I will try to crash that debug 
Haven’t been able to get a crash at start-up yet, but when switching from editor to file browser. This might be related.
I also feel like I have to change crash every fourth or fifth time to works regularly every third or fourth time
log.txt (34.8 KB)
You have a huge number of threads active, and I don’t understand why… what is the value of this setting?
Can you set it to a low non-zero value (e.g. 2 or 4) and see what happens?
It was 0.
I now tried 4 and 2 - It still crashes like half of the time in non-debug mode. But it seems to get a little further than before. It sometimes manages to build half of the thumbnails on the page or even all until it crashes.
are you using the “official” version or one of @gaaned92 optimized builds? I’m still trying to understand how you can have so many active threads as shown in the backtrace…
I used gaaneds generics because of the debug.exe. The Znver2 crashes too.
Your build from bitbucket seems solid with threads “0”. So we now know who to blame. 
I observe that the number of threads is more important when using gdb.
For release builds, I notice no real difference with official builds.
Alberto, do you cross compile on Linux? with what tools?? do you also cross compile libraw to get a recent version?
Is it possible that some dependencies are not thread safe?
I build on a windows 10 vm, but I don’t upgrade msys very often. One thing that I did is to increase the stack size for threads on windows. I have now enforced this in CMakeLists.txt, so if you rebuild the latest head of the libraw branch it should be picked up automatically. Other than that, I don’t know what might be going wrong – perhaps some of the more aggressive optimizations is buggy or (more likely) makes some bug in ART more visibile…
I notice that the crash happens when opening an image while the thumbnails are generated in the file browser.
but does this happen on your build only? in any case, can you try limiting the number of threads by setting the env var OMP_NUM_THREADS? E.g. try setting OMP_NUM_THREADS=20 or something like that before running ART, and see what happens (I’m not really sure it will help, but let’s give it a try…)
It happens also on your build, but it seems to me, less often.
The OMP_NUM_THREADS doesn’t seem to improve.
So looking at your build parameters, I see that you don’t use -mthreads. Don’t ask me for what it is good! it is an old remnant of builds ages ago. I will suppress it and rebuild with last version.
What puzzles me is either you had a libraw 0.21 on your MSYS system or you built libraw yourself. If second true, did you built with the autotools or with cmake?
Thanks for testing! Indeed, I used a self-compiled libraw built with cmake
