I think I should repeat: if it ain’t broke, don’t fix it. I normally use tcmalloc for all my programs, so I recommend to stick to it if possible. I’ve added mimalloc because I recently found out about it and I’m somewhat curious, but I don’t expect that it makes a significant difference (at least on Linux, on windows it might but I have no experience there)
@jllailes I really don’t know what’s going on with your system, those crashes are strange…no idea, sorry
For information, after a lot of compilation tests, it seems that the problem for me comes from the build-art script. Indeed, any compilation with this script generates a binary that doesn’t run anymore.
Whereas a compilation with the manual method of rawtherapee (in rawpedia) works. Art works perfectly…
I’m doing some build tests right now on my zen-based system, seems like it depends on a combination of optimization params.
Nevertheless i can say if ART compiles & runs successfully with GCC10.1, than the “pink image bug” as there as well. @Daniel_Catalina already created a bug report for ART this one:
I’m currently concentrating on the segfault on startup which might be related to tcmalloc as far as my current test data shows. I’ll try -fno-tree-loop-vectorize as well.
-fno-tree-loop-vectorize fixes the pink images but the segfault i experience on my system is most likely related to the use of tcmalloc with GCC10.1 - this may be a edge case with a specific cpu architecture/model (currently running a zen1-based Athlon 3000G). Would be interesting if some else has this behaviour as well.