Re: Bug de compilation de gros fichiers version 2.23.7

[Jean Abou Samra]

Le 09/04/2022 à 15:02, Gil So a écrit :
> Bonjour à tous !
> Il semblerais y avoir un bug, car le code suivant fonctionne 
> parfaitement en v 2.2.22 mais pas en 2.23.7
> Je l'ai découvert en compilant un gros book (Arrêté avec le code de 
> retour -2147483645."...
> Je suis sur Windows 10.
> J'utilise Frescobaldi et sur mon book il y a même une alerte qui 
> indique (Fatal error to GC "Too many heap sections")
> En enlevant quelques partitions mon book compile correctement...
> Merci à tous pour votre aide
> Gilles
>
> \version "2.23.7"
> %\version "2.22.2"
>
> mus =
> \score {
>   {
>     \repeat unfold 220
>     {
>       c'1
>     }
>   }
> }
>
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
> \mus \mus \mus \mus \mus \mus \mus \mus \mus \mus


Bonjour Gilles,

Bug, je ne dirais pas. Faisons un rapide calcul. Cette partition 
comporte 8 × 10 × 220 = 17 600 notes. Pour chaque note, il y a à peu 
près 5 grobs (NoteHead, Stem, NoteColumn, PaperColumn, 
NonMusicalPaperColumn), sans compter les systèmes, BarLine, etc., donc 
on doit se retrouver aux alentours de 100 000 grobs. Après que certains 
grobs (NonMusicalPaperColumn, BarLine et compagnie) aient été tripliqués 
à cause de la division en systèmes, peut-être 150 000 ou 200 000 grobs. 
En comptant 100 octets sur la mémoire prise pour un grob (à vrai dire je 
n'en sais rien, mais clairement 100 octets est une estimation basse), on 
se retrouve déjà rien qu'avec les grobs à 20Mo de mémoire vive 
nécessaire. À ce stade, on se heurte aux limites du système, du langage 
de programmation, etc. En l'occurrence, le message « Too many heap 
sections » provient du ramasse-miettes, le programme embarqué par Guile 
qui se charge de libérée la mémoire inutilisée. Le ramasse-miettes a 
changé entre Guile 1 et Guile 2 (les nouvelles binaires utilisent 
désormais Guile 2), ce qui peut expliquer certaines choses. Quoi qu'il 
en soit, à une telle échelle, c'est déjà surprenant (à mon avis) que 
LilyPond ait été capable auparavant de compiler la partition en 
question. La solution est d'identifier des sauts de page entre deux 
\score et de séparer le \book en plusieurs \book (essaie d'abord les 
\bookpart, cela pourrait marcher aussi, je n'en suis pas très sûr).

Cordialement,
Jean