Re: comparing crashes in 2.23.81 with 2.23.14 and 2.22.1

[Jean Abou Samra]

    Le 18/11/2022 à 07:48, Jeff Olson a écrit :

<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.

      FYI, this is going to remain unfixed for 2.24.0, but probably
      going to be
      fixed in the followup bugfix release 2.24.1 (probably around
      February).
      See
      https://lists.gnu.org/archive/html/lilypond-devel/2022-11/msg00102.html
      if you are interested in the details.
      
      Best,
      Jean

OpenPGP_signature
Description: OpenPGP digital signature