code d'arrêt 1073741819 en compilation lilypond

Général
21

Bonjour !
Merci pour ces différents fichiers qui m'ont bien aidé (surtout le dernier) !
Arnaud

···
22

De rien !

···

Le jeu. 26 sept. 2019 à 21:42, Gazagnes Arnaud <****@****> a écrit :

Bonjour !
Merci pour ces différents fichiers qui m'ont bien aidé (surtout le dernier) !
Arnaud

23

Bonjour,

Je ne sais pas si un thread reprend ce problème de code -1073741819. J'apporte mon expérience personnelle de ce pb.

chez moi le problème est en apparence parfaitement aléatoire: le même fichier, sans aucun changement, juste répéter la compil, peut stopper de compiler avec cette erreur. Si je relance la compilation plusieurs fois, ça finit toujours par passer crème. Par contre le nombre de relances à faire avant succès est variable. Et j'ai l'impression (je dis bien l'impression) que le pb arrive d'autant plus fréquemment que Frescobaldi tourne depuis longtemps sans avoir été arrêté. Quand ça arrive trop, je relance Fresco, et j'ai l'impression que ça arrange pour un temps.

Mes suspects:

  • Lock de fichier (je ne sais pas si FR/Lily multiplient les locks à mesure du nombre d'exécutions)
  • Pb mémoire (mauvais release de lock ou release différée selon l'état du processus?)
  • Un mélange des 2

Qu'en pensez-vous?

Bon après-midi,
Emmanuel

24

Bonjour,

Je ne saurais répondre sur le process du bug mais il est signalé depuis au moins 2012 sur bug-lilypond voir ici bug 1073741819
il semblerai que ce problème survient pour l'OS Windows et lors de compilation de gros fichiers.
Je ne sais pas si la solution que j'avais proposé fonctionne, soit augmenter la mémoire de swap. (je suis sous linux)

Cordialement,

25

Un plantage avec un tel code d'erreur et qui survient de manière aléatoire a 99% de chances d'être lié à la "garbage collection". Il est peu probable que ce soit le même qu'en 2012. En général, justement parce qu'ils sont non-déterministes, les bugs de ce genre sont un enfer absolu à reproduire et à corriger.

@franquemagnee Si vous avez un fichier qui reproduit le problème, ce serait utile pour vérifier s'il n'y a pas quelque chose d'inhabituel dedans qui pourrait provoquer ou juste favoriser le bug. Je ne m'attends pas à un exemple minimaliste pour ce genre de cas, vu que ces problèmes ont tendance à se produire sur de gros fichiers (quand Guile fait beaucoup de cycles GC au milieu de la compilation).

26

Bonjour Jean,

C'est cool de vous relire! :slight_smile:

Ca dépend de ce qu'on appelle un gros fichier: le mien, TTC, doit faire dans les 2k lignes, et quelques books. Donc oui Guile a un peu de boulot.

Le fait que ce bug apparaisse (de mes observations) plus facilement lorsque Frescobaldi tourne depuis longtemps plaide en effet pour suspecter un pb de mémoire (garbage inclus).

Je ne vois pas ce qui pourrait le faciliter dans ce que je fais. Sans que tout soit sans doute parfaitement honnête, il n'y a rien je pense de vraiment crapuleux.
Il faudrait voir quelles sont les tâches qui consomment plus de ressources que d'autres (parfois on a des surprises).
D'autant que le fichier finit toujours par passer, tôt ou tard. Il suffit de CTL-MAJ-P suffisamment de fois :slight_smile:

Donc si je comprends bien, le code en question est "y a une douille quelque part" mais sans qu'on sache en dire plus? Donc la philosophie de développement est de progressivement extraire les codes identifiés pour des codes dédiés?
Dans ce cas, effectivement, peu de chances que la cause soit identique à celle de 2012. Néanmoins je tiens à signaler que je suis quand même raccord avec le sujet initial du thread! :wink:

Et oui, comme le dit @MartialR le bug n'arrive que sous Windows.

Bon après-midi à tous!

27

LilyPond ne doit normalement pas segfaulter, mais n'a aucun contrôle sur le code d'erreur renvoyé par l'OS si une segfault se produit. Sous UNIX, c'est 11 (valeur standard du signal SIGSEGV), sous Windows c'est autre chose.

D'ailleurs, ce n'est certainement pas -1073741819, je doute que Windows renvoie vraiment des codes négatifs, je suis sûr qu'il y a un problème de conversion de ce code quelque part, soit dans LilyPond soit dans Frescobaldi. Ce nombre vaut exactement -230 + 5, dont la représentation binaire comme entier signé sur 32 bits est celle de -230 + 5 + 232 = 231 + 230 + 5 comme entier non signé sur 32 bits, soit 0xC0000005, ce qui d'après une rapide recherche a l'air d'être effectivement le code standard pour une segfault sous Windows.

28

Oui, c'est fort possible pour le code négatif.
Et on sait également qu'un process qui a explosé en vol par un SIGSEGV laisse généralement la mémoire dans un état proche de l'Ohio...
Et je me doute que Lilypond ne doit normalement pas segfaulter... :smiley: comme beaucoup d'applicatifs (j'en connais peu qui doivent le faire yahoo-emoticon-yahoo-messenger)

29

Bonjour à tous,

J'ajoute un petit élément de contexte, si ça peut aider les experts à comprendre ce qui se passe, et circonscrire le bug.

L'erreur à laquelle je fais face se situe TOUJOURS au même endroit de la compilation.

Démarrage lilypond.exe 2.25.23 [myFile.ly]...
Traitement de « C:/Users/.../myFile/myFile.ly »
Analyse...
Interprétation en cours de la musique...
Avertissement : Bouclage du canal MIDI
Avertissement : réaffectation modulo 16
Avertissement : Bouclage du canal MIDI
Avertissement : réaffectation modulo 16
Avertissement : Bouclage du canal MIDI
Avertissement : réaffectation modulo 16
MIDI output to `myFile_Full.mid'...
Interprétation en cours de la musique...[8][16]

!! Si l'erreur survient, alors c'est toujours ici, entre ces 2 messages !! si le message suivant arrive, alors c'est gagné.

Pré-traitement des éléments graphiques...
Détermination du nombre optimal de pages...
Répartition de la musique sur 4 à 5 pages...
Dessin des systèmes...
Conversion à « myFile.pdf »...
Compilation menée à son terme, avec succès.
Terminé avec succès en 6.8".

Note: il me semble (je n'ai pas fait rigoureusement attention, mais je suis pratiquement sûr) que l'erreur arrive indépendamment de l'occurrence de bouclages de canaux midi.

Voilà, my 0,02€
Emmanuel

30

Merci, mais ça ne permet malheureusement pas de déduire grand-chose parce que cette phase d'interprétation représente une partie conséquente du code (on passe d'une aiguille dans une grange de foin à une aiguille dans une botte de foin), et du reste il est fort possible que le problème se reproduise toujours pendant cette phase uniquement à cause de l'évolution de la consommation mémoire qui provoque des GCs vers ce moment, et autres facteurs de ce type.

31

(D'ailleurs l'analyse syntaxique et la sortie MIDI sont relativement légères, donc en réalité c'était tout à fait probable.)