ART meets the AUR

my last version compiled on Aur (1.2.77) crashes ! no pictures are displayed in the browser, and the software crashes after a few seconds. Apparently the classic compilation version with build-art is working…

Sorry, I didn’t try on windows… you can check with the equivalent of ldd (I think it’s called dependency walker on win) that the executable is actually linked against mimalloc. The library also allows to print memory usage statistics by setting some env vars, you could also try that…

well… If it ain’t broke, don’t fix it :slight_smile:

1.2.77 (with tcmalloc) works fine for me. Please launch ART from a terminal, there should be some output when the crash happens - we need this output.

Stupid question… how do I launch Art into terminal?? :shushing_face: :upside_down_face:

ok found sorry :stuck_out_tongue_winking_eye:

image

Thanks, I followed what you’ve done and it works (with self-compiled ART).

1 Like

segfault sounds strange, have you changed any essential part of your machine after building?
My first attempt would be to rebuild and reinstall.

:+1:

Some feedback to performance and memory usage would be nice.
I managed to fix the mimalloc package, so there’s no need to manually create the symlink anymore.

Hi @Guzzisti,
Ok I uninstalled and rebuilt Art from Aur, and after another crash (?) it all works now.
I looked at the Ram’s power consumption with both versions of Art (the Aur version and the self-compiled version with build-art). I did exactly the same manipulations with both softwares (going from picture to picture by zooming in at 100% and coming back to a full view) on 5 pictures). It seems that the Aur version (above) is more greedy in Ram, the performances being about the same.

strange things happen on your machine…i have no clue why “after another crash” it should work and before it did not work… :fearful:

As far as i can see build-art uses tcmalloc by default. Did you install the AUR “release” version or the “git” version? Only the latter uses TCMALLOC currently.
Do both version use the same settings (especially “Performace” tab)?

A higher ram usage is not necessarily a bad thing, it just shouldn’t skyrocket and start to use swap.

I used the git version and indeed there are the same settings in the performance tab.
Maybe the crash of the first startup is due to the fact that they are the same cache folders used for the successive versions ?
Otherwise both versions work fine, I just found it amazing that the Ram usage is different.
But with 32GB of Ram I have a lot of margin left.

I may have a weird machine, but I swear I’m not changing anything !
Every time I update the Aur repository, Art crashes with the same error as above… I have to uninstall and reinstall the software for it to start…

here is what happens when Aur version 1.2.79 crashes

image

I didn’t do a real benchmarking, but I didn’t see any significant difference between TCMALLOC and MIMALLOC in terms of performance nor in memory usage.

HELP ME please!!!
The latest version of Art doesn’t even open anymore whether it’s the Aur version or the compiled version.
I’ve uninstalled everything, reinstalled everything, it doesn’t matter. The old spotremoval branches versions work… what’s going on ? how can I get you a bug report ? I’m on Manjaro, with a 2011 pro mac. Thanks for your help.

Can this help?

erreur Art.txt (4.7 KB)erreur Art2.txt (1.5 KB)

I’ve never encountered such a behaviour, so i can only place a rough guess: maybe something got messed up when using multiple version with the same config/cache folder.

Have you tried to clean to ART-related folders in ~/.cache (and may ~/.config as well)?

On W10, I made a build with mimalloc. I verified mimalloc is linked and it seems ok.
In my normal use of ART I don’t really feel a performance difference. So my question is how to benchmark? do I need to stress ART opening a lot of editor windows? What operation to perform? What I have to measure?..

by deleting the Art folder from .cache and .config, the Aur version restarts. but not the compiled version. The problem isn’t totally solved, but… The software often crashes while loading photo files…

Thanks @guzzisti