Bug de compilation de gros fichiers version 2.23.7

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

···

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

Merci Jean pour ton retour ! Donc d’après toi c’est normal même si ça compile correctement en version 2.22.2 ?

···

Le 9 avr. 2022 à 20:10 +0200, Jean Abou Samra <****@****>, a écrit :

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

Bonjour Gilles,

Pourrais-tu abonner ta nouvelle adresse à la liste (https://lists.gnu.org/mailman/listinfo/lilypond-user-fr) ? Pour l'instant, j'approuve tes messages manuellement.

Merci Jean pour ton retour ! Donc d’après toi c’est normal même si ça compile correctement en version 2.22.2 ?

Oui. On est ici aux limites de chaque système, machine, version d'une dépendance, etc. C'est normal qu'il y ait des variations, cela n'indique pas un bug. Ta partition avait juste la malchance de se trouver proche de la limite. Sauf s'il y a une grosse différence dans la taille maximale acceptée pour une partition, ou si des partitions de taille « raisonnable » (terme évidemment subjectif) se retrouvent à ne plus compiler, « c'est la vie ».

Cordialement,
Jean

···

Le 10/04/2022 à 10:29, Gil So a écrit :

C'est là où un découpage en "bookpart" peut s'avérer utile. cela m'a permis à de nombreuses reprises de résoudre des problémes de répartition que je n'arrivais plus à gérer. J'imagine que c'est comme avaler de temps en temps plutôt que de déglutir une fois toute l'assiettée en bouche.

Cordialement,

···

Le 10/04/2022 à 14:12, Jean Abou Samra a écrit :

Le 10/04/2022 à 10:29, Gil So a écrit :

Merci Jean pour ton retour ! Donc d’après toi c’est normal même si ça compile correctement en version 2.22.2 ?

Oui. On est ici aux limites de chaque système, machine, version d'une dépendance, etc. C'est normal qu'il y ait des variations, cela n'indique pas un bug. Ta partition avait juste la malchance de se trouver proche de la limite. Sauf s'il y a une grosse différence dans la taille maximale acceptée pour une partition, ou si des partitions de taille « raisonnable » (terme évidemment subjectif) se retrouvent à ne plus compiler, « c'est la vie ».

--
Jean-Charles

J'ai essayé ça mais ça ne fonctionne pas non plus...

mus =
\score {
{
\repeat unfold 220
{
c'1
}
}
}
\book {
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
}

Bonjour Ya Gloops,

Chez-moi-ça-marche™ :

Dessin des systèmes...
Conversion à « document.pdf »...
Compilation menée à son terme, avec succès.
Terminé avec succès en 3'16".

Debian/sid, Frescobaldi 3.1.3.

Cela produit 100 pages de mémo pour débutant souhaitant participer à un In C de Riley.

Cordialement,
Frédéric

Bonjour,

testé, ça marche

Xubuntu focal, Frescobaldi 3.0.0
"vieux" Pentium(R) CPU G3420 (date de 2013)

8 go ram

Conversion à « document.pdf »...

Compilation menée à son terme, avec succès.

Avec bookpart 100 pages Terminé avec succès en 1'52".

Sans bookpart 98 pages 2'14 "

Terminé avec succès en 2'14".

···

Martial Rameaux

Ha oui précision : LilyPond 2.23.7

···

Martial Rameaux

Moi j'ai testé sur deux ordi (win10) et c'est la même chose...

···

Le 11/04/2022 à 12:12, Martial R a écrit :

Ha oui précision : LilyPond 2.23.7

Le lun. 11 avr. 2022 à 11:29, Martial R <****@****> a écrit :

Bonjour,

testé, ça marche

Xubuntu focal, Frescobaldi 3.0.0
"vieux" Pentium(R) CPU G3420 (date de 2013)

8 go ram

Conversion à « document.pdf »...

Compilation menée à son terme, avec succès.

Avec bookpart 100 pages Terminé avec succès en 1'52".

Sans bookpart 98 pages 2'14 "

Terminé avec succès en 2'14".

Le lun. 11 avr. 2022 à 10:27, F. Moinard <****@****> a écrit :

Bonjour Ya Gloops,

Chez-moi-ça-marche™ :

Dessin des systèmes...
Conversion à « document.pdf »...
Compilation menée à son terme, avec succès.
Terminé avec succès en 3'16".

Debian/sid, Frescobaldi 3.1.3.

Cela produit 100 pages de mémo pour débutant souhaitant participer à un In C de Riley.

Cordialement,
Frédéric

--

Martial Rameaux

--

Martial Rameaux

Et en y allant carrément plus, est-ce que ça marche ?

\version "2.22.2"

mus =
\score {
{
\repeat unfold 220 { c'1 }
}
}

\book {
\bookpart { \mus \mus }
}

En fait, je soupçonne l'exemple de ne pas être réaliste, car comme
les mesures sont très petites en termes d'espace (car elles ne
contiennent qu'une note), il y a énormément de configurations possibles
pour les sauts de ligne. D'expérience, LilyPond a plus de facilités
avec des partitions ordinaires qu'avec des \repeat unfold ... { c'1 }.
Pour moi, la vraie question est : quel est ton \book (est-ce une partition
orchestrale, combien d'instruments, de pages, ...), et est-ce que
tu arrives à le faire compiler en le séparant en un nombre acceptable
de \bookpart ?

Cordialement,
Jean

···

Le 10/04/2022 à 21:53, Ya Gloops a écrit :

J'ai essayé ça mais ça ne fonctionne pas non plus...

mus =
\score {
{
\repeat unfold 220
{
c'1
}
}
}
\book {
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
}

En version 2.22.2 tout fonctionne sans problème, mais en 2.23.7 c'est toujours le même problème...
Mon book contient un bookpart par partition mais il y en a plus de 200...

J'ai essayé ça mais ça ne fonctionne pas non plus...

mus =
\score {
{
\repeat unfold 220
{
c'1
}
}
}
\book {
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
\bookpart {
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
\mus \mus \mus \mus \mus \mus \mus \mus \mus \mus
}
}

Et en y allant carrément plus, est-ce que ça marche ?

\version "2.22.2"

mus =
\score {
{
\repeat unfold 220 { c'1 }
}
}

\book {
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }
\bookpart { \mus \mus }

}

En fait, je soupçonne l'exemple de ne pas être réaliste, car comme
les mesures sont très petites en termes d'espace (car elles ne
contiennent qu'une note), il y a énormément de configurations possibles
pour les sauts de ligne. D'expérience, LilyPond a plus de facilités
avec des partitions ordinaires qu'avec des \repeat unfold ... { c'1 }.
Pour moi, la vraie question est : quel est ton \book (est-ce une partition
orchestrale, combien d'instruments, de pages, ...), et est-ce que
tu arrives à le faire compiler en le séparant en un nombre acceptable
de \bookpart ?

Cordialement,
Jean

···

Le mardi 12 avril 2022, 20:37:59 UTC+2, Jean Abou Samra <****@****> a écrit :
Le 10/04/2022 à 21:53, Ya Gloops a écrit :

Ah, dommage. Et avec plusieurs \book ? Là, je ne vois pas de raison…
Par contre, il faudra les fusionner en un seul PDF à la fin.

Cordialement,
Jean

···

Le 12/04/2022 à 22:01, Ya Gloops a écrit :

En version 2.22.2 tout fonctionne sans problème, mais en 2.23.7 c'est toujours le même problème...
Mon book contient un bookpart par partition mais il y en a plus de 200...

Ca fonctionne avec que des book à la place des bookpart mais adieu la table des matière....

···

Le mardi 12 avril 2022, 22:10:14 UTC+2, Jean Abou Samra <****@****> a écrit :

Le 12/04/2022 à 22:01, Ya Gloops a écrit :

En version 2.22.2 tout fonctionne sans problème, mais en 2.23.7 c'est toujours le même problème...
Mon book contient un bookpart par partition mais il y en a plus de 200...

Ah, dommage. Et avec plusieurs \book ? Là, je ne vois pas de raison…
Par contre, il faudra les fusionner en un seul PDF à la fin.

Cordialement,
Jean

Bonjour,

Deux mois plus tard…

Je l'avoue, j'ai été trop pessimiste. En fait, il était possible
d'activer une option du ramasse-miettes pour l'aider à allouer de telles
quantités énormes de mémoire. Ce sera fait dans la prochaine version. Voir

https://gitlab.com/lilypond/lilypond/-/merge_requests/1419

Et si vous êtes impatient, j'ai mis ici des binaires compilées avec
cette option :

http://abou-samra.fr/lilypond-2.23.10-mingw-x86_64.zip

Cordialement,
Jean

Wouaww !!! Génial Jean je vais essayer ça tout de suite…

···

Le 19 juin 2022 à 10:28 +0200, Jean Abou Samra <****@****>, a écrit :

Bonjour,

Deux mois plus tard…

Je l'avoue, j'ai été trop pessimiste. En fait, il était possible
d'activer une option du ramasse-miettes pour l'aider à allouer de telles
quantités énormes de mémoire. Ce sera fait dans la prochaine version. Voir

https://gitlab.com/lilypond/lilypond/-/merge_requests/1419

Et si vous êtes impatient, j'ai mis ici des binaires compilées avec
cette option :

http://abou-samra.fr/lilypond-2.23.10-mingw-x86_64.zip

Cordialement,
Jean

CA MAAAARCHE !!!
Enorme bravo Jean...
Gilles

Wouaww !!! Génial Jean je vais essayer ça tout de suite…

···

Le dimanche 19 juin 2022, 10:34:21 UTC+2, yagloops <****@****> a écrit :

Le 19 juin 2022 à 10:28 +0200, Jean Abou Samra <****@****>, a écrit :

Bonjour,

Deux mois plus tard…

Je l'avoue, j'ai été trop pessimiste. En fait, il était possible
d'activer une option du ramasse-miettes pour l'aider à allouer de telles
quantités énormes de mémoire. Ce sera fait dans la prochaine version. Voir

https://gitlab.com/lilypond/lilypond/-/merge_requests/1419

Et si vous êtes impatient, j'ai mis ici des binaires compilées avec
cette option :

http://abou-samra.fr/lilypond-2.23.10-mingw-x86_64.zip

Cordialement,
Jean

Moi je n'y suis pour presque rien, c'est Jonas Hahnfeld qu'il faut
remercier.

Cordialement,
Jean

···

Le 19/06/2022 à 10:53, Ya Gloops a écrit :

CA MAAAARCHE !!!
Enorme bravo Jean...
Gilles

Enorme merci à Jonas Hahnfeld aussi, je suppose qu'il est inscrit dans la liste anglaise...

···

Le dimanche 19 juin 2022, 10:54:40 UTC+2, Jean Abou Samra <****@****> a écrit :

Le 19/06/2022 à 10:53, Ya Gloops a écrit :

CA MAAAARCHE !!!
Enorme bravo Jean...
Gilles

Moi je n'y suis pour presque rien, c'est Jonas Hahnfeld qu'il faut
remercier.

Cordialement,
Jean

Bonjour,

Pour info, la 2.23.10 vient de paraître avec cette correction. Comme
d'habitude, les binaires sont ici :

https://lilypond.org/development.fr.html

Comme les binaires que j'ai postées n'étaient pas officielles et ne
provenaient pas tout à fait des mêmes sources (il y a eu des changements
entre temps), je recommande de passer à la 2.23.10 officielle. (C'est
plus facile sur la liste si \version "2.23.10" ne cache pas des
différences de ce genre.)

Cordialement,
Jean