<amateur guessing>
The attached score generator hints that the crashes in these three
releases may be different manifestations of the same 32-bit address limit.
A previous thread
(https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00189.html)
indicated a fixed was being worked for "exited with return code
-1073741819" in 2.23.14 and that 2.23.81 was "better in this respect,
although the problem remains in very intensive situations".
Since this is a blocking issue for my large projects, I used a
light-weight score generator (see attached tst22381.ly and
gen-scores.ily) that simulates my projects to test the breaking points
of these three releases. All you do to run it is change the version
number and set the number of scores. It then generates a simple but
large document with the specified number of scores where the scores vary
pseudo-randomly in size, to simulate the variations in my project. I've
been running it from Frescobaldi 3.1.1 on Windows 10, increasing the
number of scores until it crashes. Takes about 1'14" per run on 2.23.81.
Here are the repeatable results for these releases:
2.22.1 runs up to 625 scores, whereupon lilypond reaches the 32-bit
address limit (~2G on my 64-bit Windows 10) and gets bad-alloc.
2.23.14 runs up to 413 scores, beyond which it returns 1073741819.
2.23.81 runs up to 418 scores, beyond which it returns 1073741819.
Coincidentally (?) all of these failures are at about the same memory
usage (~2G) as measured in Task Manager. Of course 2.22.1 being 32-bit
has a hard limit, but the 2.23 releases should be able to cruise past
that limit.
The theory that unites these is that the segmentation fault implied by
1073741819, so I hear, is typically due to a bad pointer leading outside
the boundaries of the process's memory segment. Perhaps after the
porting 2.23.x to 64-bits, there remains a pointer variable somewhere
that is still typed for 32 bits. So when the number of scores pushes
memory consumption above the 32-bit size and the code with the 32-bit
wide pointer eventually gets executed, bang, you get a 1073741819. Or
something like that. Just an amateur guess.
My projects have about 1200 scores, hence my interest in helping however
I can, as a user not a developer. Perhaps real developers may be able to
use this score generator to prove in the fix.
HTH,
Jeff
\version "2.23.81"
% number of score to generate
#(define numscors 418)
\header {
title = \markup { "Version " #(lilypond-version)" with " #(number->string numscors) " scores" }
tagline = ##f
}
\paper {
#(set-paper-size "letter")
indent = 7\mm
top-margin = 15\mm
bottom-margin = 15\mm
left-margin = 15\mm
right-margin = 15\mm
ragged-last-bottom = ##t
page-breaking = #ly:page-turn-breaking
}
\include "gen-scores.ily"
$@(scors numscors)
% final values
#(format #t "exn=~d i=~d mincat=~d maxcat=~d~%" exn i mincat maxcat)
%{
convert-ly.py (GNU LilyPond) 2.23.14 convert-ly.py: Processing `'...
Applying conversion: 2.23.1, 2.23.2, 2.23.3, 2.23.4, 2.23.5, 2.23.6,
2.23.7, 2.23.8, 2.23.9, 2.23.10, 2.23.11, 2.23.12, 2.23.13, 2.23.14
%}
%{
convert-ly.py (GNU LilyPond) 2.23.81 convert-ly.py: Processing `'...
Applying conversion: The document has not been changed.
%}
\version "2.23.81"
% some sequential music objects (fragments to be concatenated by gen-music
function)
xa = { g'4. a'8 g'4 f' e' f' g'2 d'4 e' f'2 e'4 f' g'2 g' a'4 g'8 f' e'4 f' g'2
}
xb = { d'4 e' f'4 e' f' g'8 f' e'4 f'8 g' a'4 c'' e''4 d''8 c'' b'4 cis'' d''2 }
xc = { a'4 b' c''4 b' c'' d''8 c'' b'4 c''8 d'' e''2~ e''4 d''8 c'' b'4 cis''
d''2 }
xd = { a'4 b' c''4 b' c'' d''8 c'' b'4 g'8 f' e'4 d' cis'4 a'8 g' a'4 cis''
d''2 }
xe = { d''4 c'' b'4 g'8 f' g'4 b' c''4 d'' e''2 d''4 c''8 b' a'4 b' c''2 }
xf = { g'4 a' bes'4 a' bes' c''8 bes' a'2 b' c''4 b' c'' d''8 c'' b'4 a' bes'2
a'4 g'8 f' e'4 fis' g'2 }
xg = { d'4 e' f'4 e' f' g'8 f' e'4 c''8 b' a'4 g' fis'4 d''8 c'' d''4 fis' g'2 }
xh = { g'4 f' e'4 c''8 bes' c''4 e' f'4 a'8 g' f'4 e' d'2 g' e'4 c' }
% list of sequential music objects
smolist = #(list xa xb xc xd xe xf xg xh)
% to get a scheme list of music elements from a music object
#(define (get-elements mus) (ly:music-property mus 'elements))
% list of element-lists
elists = #(map get-elements smolist)
enum = #(length elists)
% recursively concatenate a range of elists (0 <= m <= n, possibly > enum)
#(define (cat-elists m n)
(let ((elist-m (list-ref elists (modulo m enum))))
(if (< m n) (append elist-m (cat-elists (1+ m) n)) elist-m )))
% force a fixed seed (pseudo-random)
#(set! *random-state* (seed->random-state 42))
% generate music by concatenating contiguous members from list.
% i mod enum is the starting position in the list for the next gen-music.
% mincat is the minimum number of concatenations (mincat >= 0)
% maxcat is the max number of concatenations (maxcat >= mincat)
% actual number of cats is random between mincat and maxcat.
i = 0
mincat = 2
maxcat = 12
gen-music = #(define-music-function () ()
(let* ((m i) (n (+ m (+ mincat (random (1+ (- maxcat mincat)))))))
(set! i (1+ n))
(make-sequential-music (cat-elists m n))))
% each invocation of scr generates one new score
exn = 0
scr = #(define-scheme-function () ()
(set! exn (1+ exn))
#{
\score {
\header { piece = \markup{ \bold { "No. " #(number->string exn) } } }
{ \gen-music \bar "|."} }
#} )
% scors generates a specified number of scores
% e.g. invoke $@(scors 10) from lilypond to generate ten scores
#(define (scors num) (map (lambda (i) (scr)) (iota num)))
%{
convert-ly.py (GNU LilyPond) 2.23.14 convert-ly.py: Processing `'...
Applying conversion: 2.23.1, 2.23.2, 2.23.3, 2.23.4, 2.23.5, 2.23.6,
2.23.7, 2.23.8, 2.23.9, 2.23.10, 2.23.11, 2.23.12, 2.23.13, 2.23.14
%}
%{
convert-ly.py (GNU LilyPond) 2.23.81 convert-ly.py: Processing `'...
Applying conversion: The document has not been changed.
%}
