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
Hi,
I have rewritten the threading part. It would be good if people could test this (especially on windows) to see if it improves stability.
Thanks in advance!
OK, going to test. thanks
Edit: that’s a massive modif!
edit: 
Now it crashes as soon I open a folder containing images. (either with or without -mthreads).
Debug show no information.
Can you try this build?
https://drive.google.com/file/d/1xlf9Kdycd4BvQQ-rczBWsNgo5qf6M433/view?usp=sharing
It works here…
This seems to work okay for me. In general I have usually have no problems with ART…one window of time I found if I advanced too fast from image to image I would get crashes. I think that was noted and corrected but in general ART doesn’t crash…I use the nightly builds and update fairly often…Using WIndows 10 on some “older” hardware…
Opened 10 - 12 photos so far, crashed 2 times when opening photos.
What machine do you have? Which CPU, how many cores, how much RAM? I really have no clue what is going on… I tried very hard to make it crash here, but so far I’ve been unsuccessful 
AMD Ryzen 5 3600 6-Core Processor (12 threads)
32 GB RAM
Windows 11 and software running on a WD Blue M.2 SSD.
Currently, your official stable release works best for me. It crashes too from time to time, but rather seldom.
Same observations as @apostel338 .
It seems to me that my builds are going worst and worst. Some reasons I imagine:
-
use of different build flag.
-
problem with the compiler, I use GCC 11.2.0
-
new version of some dependency is faulty, but which one?
So I can try
- to use the same build flags as you
- revert the compiler to GCC 10.3.0
- for the 3rd point I don’t know what to do.
For RawTherapee I downgraded to gcc 10.3.0 because I had crashes with gcc 11.2.0 builds…
2 Likes
Thanks that could explain the issue
1 Like
Just trying ART_master_1.8.2-228-ge2356c271_W64_Skylake_211109 and it crashes a microsecond after fully opening.
I did d/l a few versions in the last 3 days and they did open for me. Not that one.