problème plantage depuis mise à jour

Autour de darktable Développement
1

Bonjour,

J’ai un plantage systématique depuis la mise à jour cette après-midi

Version 3.1.0~git1850.286874047 sur Ubuntu 20.04 et dépôt Opensuse

lviatour@Luc-20-04:~$ darktable
Erreur de segmentation (core dumped)
Unable to attach: program terminated with signal SIGSEGV, Segmentation fault.
/home/lviatour/6420: Aucun fichier ou dossier de ce type.
lviatour@Luc-20-04:~$ warning: Currently logging to /tmp/darktable_bt_7M8HL0.txt. Turn the logging off and on to make the new setting effective.
/usr/share/darktable/gdb_commands:2: Error in sourced command file:
No stack.

ET LE LOG TMP:

this is darktable 3.1.0~git1850.286874047 reporting a segfault:

warning: Currently logging to /tmp/darktable_bt_7M8HL0.txt. Turn the logging off and on to make the new setting effective.
/usr/share/darktable/gdb_commands:2: Error in sourced command file:
No stack.

Meme en virant tout le dossier config de darktable et le cache vignette et donc revenir à une configuration d’origine j’ai un plantage immédiat à l’ouverture d’un photo raw. Et ce même si c’est un nouveau dossier et une nouvelle photo sans xmp.

J’ai désinstallé DT et ré-installé pareil.

J’ai installé la version 3.02 et là tout fonctionne, je soupçonne donc bien un problème dans la version master de cette après-midi.

2

Salut Luc,

Je suis à la dernière version d’hier et je n’ai pas ce bug. Il y a un commit de houz qui a l’air de bouger certaines choses et un autre sur les infos images de jenschannoschlaw. Les autres commits sont exclus puisque modification du fichier README et de la langue espagnole… Peut-être devrait-tu essayer un commit précédent déjà pour voir si ton problème viendrait d’un commit d’aujourd’hui ?

Celui que j’utilise d’hier : 3.1.0+1847~g2c8557e4c

3

J’ai fais une mise à jour ce matin et je n’avais pas de problème.

C’est la mise à jour faite après 18:30 qui pose problème.

Comme j’utilise le dépôt Master OpenSuse aucune idée de comment revenir en arrière.

Pour le moment j’ai désactivé le dépôt master et supprimé darktable puis j’ai installé le dépôt classique et j’ai donc une version 3.02 qui fonctionne.

Par contre, je n’ai plus mes pré-réglages, mes styles et préférences qui ne peuvent revenir en version 3.02

Je vais donc attendre jusque demain voir si un nouvel update change quelque-chose.

Seul problème c’est que j’ai prévu un live débutant demain 16h sur Youtube…

4

Avec la 3.1.0~git1852.78a1a1da6 pas de pb de stabilité sur Ubuntu 18.04.4.
Dépôts opensuse aussi.

5

Vérifie dans ton dossier /var/cache/apt/archives/, si tu n’aurais pas le paquet précédent et force l’installation de ce paquet pour revenir en arrière.

6

Merci je viens d’apprendre quelque-chose :wink:

J’ai repris le .deb dans les archives créé ce matin 10h30 et cela fonctionne.

Il y a donc bien un bug sur les motifs après 10h30.

7

Ou pas, ça dépend sans doute de la conf de base. En tout cas la 1852 ne plante pas sur la mienne.

8

je comprends pas car j’ai supprimé le dossier de config et même comme cela j’ai un plantage, don la config de base est celle par défaut.

9

Peut-être un bug spécifique au paquet aussi (la compil de la master est automatique). Tu as essayé aussi le dernier paquet 1852 ? Ca vaudrait le coup de vérifier si ça fait pareil (conserve le paquet que tu as récupérer dans le dossier que j’ai cité pour revenir en arrière si besoin). Si avec le paquet 1852, ça fonctionne, ça signifierait simplement que c’est juste le paquet (et non pas le commit, rien n’a corrigé les commits entre ces paquets) qui pose problème.

En tout cas, ça peut clairement pas être ta config de base le problème (ou au pire, un type de traitement, réglage spécifique qui poserait problème avec un des derniers commits).

10

J’ai compilé cet après-midi :

Pas de problème à l’utilisation.

11

Je viens de télécharger le 1852 le bug est présent plantage immédiat à l’ouverture d’un raw…

Je dé-installe le 1852 je ré-installe le 1850 et plantage. Je récupère mon backup du dossier config et la version 1850 fonctionne.

Comme si le 1852 modifie quelque-chose dans le dossier config qui fait planter.

12

Je viens aussi de compilé la 1852. Pas de problème à l’ouverture d’un Raw.

13

@jpg54, @LViatour et les autres : restez si possible sur une master d’hier (30 mai) et pas d’aujourd’hui. @Mark-64 vient de signaler le même problème que Luc et a fait des tests et ça pointe sur le commit du jour par @houz (ça n’est pas le premier commit qu’il sort qui fout le bordel…) et avec la 1852, impossible d’utiliser les boutons de rotation du module en table lumineuse qui fait crasher darktable (même si perso je n’ai pas le problème d’ouverture en chambre noire, c’est lié).

Bref, je vais revenir moi-même en arrière et attendre avant de remettre à jour la master.

Edit : un autre utilisateur vient de poster un autre problème d’import qui fait crasher darktable depuis ce même commit d’houz. Moralité : quand houz poste un commit, se méfier et attendre avant de compiler…

14

En même temps utiliser une master c’est un risque calculé, faut assumer ses choix :wink:

Je vais donc attendre un correctif.

15

Je suis encore en 1806. Il faut vraiment que j’apprenne à naviguer dans les commits sur git pour pouvoir me débrouiller tout seul.

Merci de l’avertissement.

16

Si tu compile depuis la master et que tu veux compiler sur un commit précis (par exemple, avant celui incriminé ici), dans le dossier source, tu fais :

git checkout numéro-de-commit

Où numéro-de-commit, se récupère sur la page suivante de github : https://github.com/darktable-org/darktable/commits/master et tu clique ensuite sur le numéro abrégé du commit à droite de la ligne choisie pour afficher le détail du commit. Tu trouveras ensuite le numéro de commit complet (il est long). Et tu fais un copier-coller.

Puis tu lances la compil.

Tu peux aussi annuler le commit incriminé sur la dernière version de la master, donc après

git pull

en faisant

git revert numéro-de-commit

Attention quand même, annuler un commit peut parfois foutre le bordel (si un autre commit lié a été ajouté par exemple) donc à utiliser avec parcimonie.

17

le problème semble corrigé, je viens de faire une mise à jour et plus de problème.

18

Reste vigilant tout de même. Pascal a posté hier soir un commentaire sur son commit qui a été jusque-là superbement ignoré par houz (alors qu’il a répondu au rapport de bug sur le problème que tu as rencontré ainsi que le mien). Et ce que Pascal signale, c’est que ça casserait colorin. Pascal précise qu’en lançant darktable depuis la console, dès l’activation d’un module en chambre noire, le message d’erreur suivant apparaît :

[dt_ioppr_get_work_profile_type] can't get colorin parameters

Je te conseillerai de vérifier ça, la gestion de la couleur c’est pas rien. Pascal précise que ça apparaît surtout si le profil d’histogramme est défini sur profil de travail dans le menu d’épreuvage écran ou de gamut.

19

Je viens de compiler la 1862, pas de problème avec ni à l’ouverture d’un RAW ni avec filmique et égaliseur de ton. J’ai essayé aussi de rotation sans problème.

20

Ca c’est normalement réglé. houz a répondu à ça et poster 2 commits correctifs. L’incertitude reste sur colorin (donc la bonne utilisation du profil de couleur d’entrée et ce que j’ai souligné). Tu as vérifié ça en lançant depuis le terminal ?

Edit : je viens de faire un test et je ne reproduis pas le problème posté par Pascal, ça doit donc aussi être réglé. Tant mieux mais je resterais toujours méfiant dès qu’houz poste un commit. Ce n’est pas tant qu’il ne poste pas des bonnes choses mais sa manière de faire et ce qui en résulte parfois qui est pénible.