Plantages à l'export (mais pas que) sous Linux Mint

Bonjour,

comme je l’ai dit dans ma présentation, j’utilise Darktable depuis 2018, et je l’aime bien malgré ses défauts. Mais depuis des mois (sans doute même au moins deux ans car je suis patiente), Darktable plante systématiquement quand je l’utilise. Cela arrive très souvent au moment d’exporter les photos, mais pas exclusivement. Ça peut être au défilement dans la chambre noire, ou quand je zoome dans la photo. Au mieux, il se ferme brutalement, au pire il me freeze l’ordi complet. Cela se produit aussi bien avec les photos provenant du Lumix FZ300, du Fujifilm X30, de mon téléphone et même de vieux fichiers JPG d’appareils non identifiés.

Tout ça sur une machine qui le supportait très bien jusqu’à ce que ce problème commence. Mon PC portable n’est pas un foudre de guerre, il a 6 ans. C’est un CPU core i5 9ème génération (2.40GHz × 4), il y a 8Go de mémoire RAM et une carte nvidida GP107M avec 3Go de VRAM. Et j’utilise Linux Mint Cinnamon comme OS (actuellement j’ai une version 22.3 fraîchement installée). Le SSD de l’ordi est pratiquement vide à part l’OS. Mes photos sont sur un disque dur externe WD My Passport Ultra d’1 To, mais ça plante aussi quand je travaille avec des fichiers sur le SSD du PC. J’utilise souvent un écran Iiyama Prolite 27 pouces branché en HDMI. Les plantages se produisent avec ou sans.

Après chaque plantage, la base de données est verrouillée. Il faut donc la déverrouiller et redémarrer. Les paramètres modifiés pendant la session qui a crashé ne sont pas enregistrés (par exemple la taille pour l’export) mais les modifications dans les photos oui.

Depuis les premiers plantages, j’ai essayé :

  • d’installer une version plus récente que celle fournie par l’OS, toujours en retard de plusieurs versions ;
  • d’utiliser la version Flatpack ;
  • de désactiver l’OpenCl dans les préférences comme c’est proposé dans ce fil ;
  • de configurer l’ordinateur pour qu’il n’utilise que la carte graphique Intel et pas la NVIDIA, ou alors la NVDIA exclusivement (mode performance) ;
  • de changer de version de Linux Mint (ça fait plusieurs noyaux que les plantages persistent).

Cela n’a jamais résolu le problème. Depuis le temps que ça dure, plusieurs versions de Darktable y sont passées, jusqu’à la plus récente en flatpack.

Après un appel sur Mastodon, @manu m’a proposé d’installer une version à partir des dépôts OBS.

Sauf que j’obtiens ces messages préalables et que du coup je n’ai même pas envie de tenter l’installation :

Copie écran du terminal

Ce que je n’ai pas testé :

  • ajouter de la RAM à l’ordi (à 150€ la barrette de 16M, j’hésite un peu sans savoir si ça va marcher, vu que tout le reste fonctionne très bien) ;
  • changer de disque dur externe pour un SSD afin que les accès disque soit plus rapides ;
  • le petit dépanneur tech du coin à qui j’ai écrit un mail me répond par ailleurs « il est impossible de modifier ou remplacer la carte graphique NVIDIA puisqu’elle est soudée à la carte mère ».

Bref, au moment où je vous écris, j’ai complètement désinstallé DT flatpack, remis en place la version « paquet système » 4.6.1 fournie par l’OS, et j’hésite à tester d’autres logiciels, à contrecœur.
Je viens donc ici en dernier recours, pour demander de l’aide à la communauté sur les conseils de @manu.

Merci d’avoir lu ce long message. J’ai essayé de mettre le plus de détails possible pour vous donner des pistes de réflexion.
J’espère qu’on va trouver ensemble une solution pour que je puisse continuer à utiliser Darktable :slightly_smiling_face:

Bonjour @maia

Dans la copie d’écran du terminal, on dirait que dans la commande curl… il y a un espace entre https:// et download.opensuse.org

Ce qui expliquerait assez l’erreur curl: (3) URL rejected: No host part in the URL suivie de bash: download.etc.etc

Donc si tu veux installer darktable comme proposé sur le site d’OBS, il faut bien copier/coller les commandes. :wink:

echo 'deb http://download.opensuse.org/repositories/graphics:/darktable/xUbuntu_24.04/ /' | sudo tee /etc/apt/sources.list.d/graphics:darktable.list
curl -fsSL https://download.opensuse.org/repositories/graphics:darktable/xUbuntu_24.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/graphics_darktable.gpg > /dev/null
sudo apt update
sudo apt install darktable

Sachant que, toujours d’après la copie d’écran du terminal, la 1ère ligne/commande est bien passée (donc inutile de la repasser).

Une suggestion d’un autre test : faire une copie locale de la ou des photos à traiter.
Dans la table lumineuse, tu sélectionnes la ou les photos que tu vas traiter et dans le module Action sur la sélection dans la colonne de droite, tu cliques sur Copier localement.

Comme tu le découvriras peut-être dans la doc :

Copier localement
Crée, sur le disque local, des copies locales des images sélectionnées. Ces copies seront ensuite utilisées lorsque les images originales ne seront pas accessibles (voir Copies locales).

Ce test devrait permettre d’éliminer des causes possibles de crash (si par exemple c’est lié au disque externe).

Et enfin, si tu lances darktable à partir du terminal avec l’option -d all le journal qui s’affiche devrait permettre d’en savoir plus sur la cause du crash.

Effectivement, comme le propose @manu, nous conseillons toujours la version proposé par dépôts OBS ou la version AppImage qui est proposée sur la page darktable.org
Effectivement, une extention de la RAW à au moins 16 Mo pourrait amélioré ce problème, pour savoir si le SSD est un SATA ou en PCI sur ton ordinateur ? Il n’est pas du tout sûr que de vouloir utiliser l’OpenCL de le NVidia accélère ou soit plus performant que celui proposé par ton processeur.
Pour ton FZ300, comme le comfirme zakfm sur ta présentation, le .RW2 du Fz300 sont parfaitement dématricés ainsi que la correction d’objectif :

Pour la RAM, ce sera plutôt 16 Gigaoctets que Megaoctets… :laughing:

Mais a priori je ne dirais pas que ce sont les 8Go actuels qui fassent planter darktable. Au pire, ça serait plus lent. J’ai longtemps fait tourner dt avec 8Go sur Ubuntu sans crash.

Question : As-tu déjà essayé de réinitialiser la configuration ?

Si tu ne l’a pas fait ça serait à tester.

Et si tu t’en sens la capacité, tu peux lancer darktable en copiant/collant cette ligne :
darktable -d all | tee > /tmp/dt.log 2>&1

Tu n’auras plus qu’à partager le fichier /tmp/dt.log sur un site de partage comme SwissTransfer - Envoi sécurisé et gratuit de gros fichiers (choisir Lien), par exemple.

Bonsoir tout le monde, et merci pour vos suggestions.

  • @manu : effectivement, en utilisant les bonnes commandes, ça fonctionne mieux :wink: À partir de maintenant les tests concernant ce fil seront donc menés avec la version des dépôts OBS (5.4.1 pour le moment). Je vais travailler avec les copies locales, et on verra bien. Concernant la commande avec -d all, si je comprends bien, je lance le logiciel comme ça, je fais mes trucs avec DT jusqu’à ce que ça plante en laissant la console ouverte, et on aura des infos sur le crash dans les dernières lignes ? (je demande parce que ça génère beaucoup de lignes !!)
  • @jpg54 : concernant le disque dur, je n’en ai aucune idée. Comme la chaleur de ces derniers jours a aggravé les plantages, j’ai ouvert et nettoyé mon PC donc en voici une photo, si ça peut aider à répondre à la question…
Intérieur du PC portable Lenovo

Pour les RAW, j’ai ouvert un nouveau fil afin de ne pas mélanger les sujets.

  • @jpverrue : a priori oui, et même plusieurs fois, puisque je suis repartie d’une configuration Linux propre encore récemment, sans importer le moindre fichier de config que j’aurais pu sauvegarder. Depuis deux ans, j’ai réimporté je ne sais pas combien de fois mes photos :confused:
    Heureusement que j’utilise les fichiers XMP et que je ne perds pas mes travaux sur les photos.

Encore merci à tout le monde pour l’accueil en tous cas :blush:

Oui, et c’est normal. Le switch -d est pour debug et all, c’est « crache tout ».

Mais si tu suis la commande que j’ai indiquée ensuite (avec le tee…), tu n’auras plus qu’un fichier log à fournir.
Attention, pas de redémarrage machine (reboot) entre le crash et la récupération de /tmp/dt.log car /tmp est (normalement) purgé à chaque reboot.

Oups, des fois, je me mélange les pieds Ko, Mo, Go, To

Bonjour @manu,
J’ai donc utilisé cette version toute propre de DT jusqu’à ce qu’il plante. Il est (re)configuré comme d’habitude, avec mes styles importés, le nombre approximatif de collections que j’utilise (j’ai cessé de réimporter tout mon disque après le début des plantages), et le flux de travail « relatif à la scène » dupliqué et personnalisé.

Il a planté une première fois pendant que j’étais en train de personnaliser le flux de travail, mais je n’avais pas lancé le traçage du log. Je l’ai donc re-démarré avec ta commande, et attendu qu’il plante à nouveau en bidouillant simplement quelques photos, sans utiliser la fonction de copie locale pour être dans les mêmes conditions que d’habitude.

Le log est ici.

Merci @maia

Bon ben… en premier lieu ça ne vient pas du GPU qui est reconnu mais non activé (pas utilisé). Et d’ailleurs tu avais écrit précédemment que dans les Préférences > Traitement > Activer le support d’OpenCL n’était pas coché.

1,4088 [opencl_init] FINALLY: opencl PREFERENCE=OFF is AVAILABLE and NOT ENABLED.

Après, la fin est un peu en queue de poisson, on voit que dt est sur le module bilateral (nom « interne », pas celui du module dans l’interface utilisateur) au moment du plantage, mais pas trace d’une erreur manifeste.
Quel module ? Retouche ? Mappage de ton ? Flou ? Ombres et hautes lumières ?
Tu sais ?

Je vois pas… Mais ça mériterait une « issue » sur le github (beurk) de darktable, avec ce log bien sûr.

Désolé de pas aider plus…

Oh bah ne soit pas désolé, c’est déjà beaucoup d’avoir passé du temps à m’aider et à regarder ce fichier de log.

Je ne me souviens déjà plus de ce que j’étais en train de faire, mais ces plantages arrivent dans n’importe quel contexte. C’est très souvent au moment d’exporter les photos, mais ça peut arriver pendant le traitement dans la chambre noire, ou pendant que je fais défiler les photos dans la table lumineuse. Le premier plantage tout à l’heure s’est produit pendant que j’étais en train de personnaliser le flux de travail. J’ai l’impression que ce n’est pas lié à une action particulière.

J’ai suivi ton conseil et ouvert une issue du coup

À la réflexion, je me demanderai si ça m’arrivait si ça ne viendrait pas du système, une limite atteinte quelque part.
Mais pas nécessairement la RAM car on lit dans le log à la ligne 593 :
1,0369 [dt_configure_runtime_performance] found a sufficient 64-bit system with 6794 Mb ram and 8 cores

Ces plantages ne se produisent-il lorsque d’autres « grosses » applis gourmandes tournent, genre OpenShot, GIMP (difficile à cerner lesquelles) ?

Autre interrogation, d’autres applis tournent-elles en même temps que darktable ?

Peut-être voir ce qu’il y a à la fin de dmesg juste après le crash de darktable : [edit] tail -t 50 /var/log/dmesg et ou /var/log/syslog

Et puis donc voir si dt plante quand il bosse sur une « sopie locale ».

Autre test, peut-être : dans Préférences > Traitement > Ressources de darktable choisir Faibles

D’autres possibilités, lancer darktable dans un terminal via :

darktable --conf resourcelevel="reference"

et si pas mieux alors :

darktable --conf resourcelevel="notebook"

D’accord avec manu. Cela fait penser à une surchauffe du CPU. En lançant simplement darktable en ligne de commande cela ne pourrait pas indiquer le coupable au moment du crash ?

Bonjour tout le monde :slight_smile:

a priori l’enquête est close, il faut que je rachète de la RAM. Voir l’issue sur Github.

Merci encore!
(je ne vois pas comment clôturer le thread, je suppose qu’il faut être modo ?)