>> Masamichi HOSODA <truer...@sea.plala.or.jp> writes:
>>
>>>> Masamichi HOSODA <truer...@sea.plala.or.jp> writes:
>>>>
>>>>> In mingw, lilypond crashes as follows.
>>>>> Does someone know this reason?
>>>>>
>>>>> ```
>>>>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>type test.ly
>>>>> { c d e f g a b }
>>>>>
>>>>> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
>>>>> GNU LilyPond 2.19.16
>>>>> Processing `test.ly'
>>>>> Parsing...
>>>>> test.ly:1: warning: no \version statement found, please add
>>>>>
>>>>> \version "2.19.16"
>>>>>
>>>>> for future compatibility
>>>>> Interpreting music...
>>>>> Preprocessing graphical objects...terminate called after throwing an
>>>>> instance of
>>>>> 'std::bad_alloc'
>>>>> what(): std::bad_alloc
>>>>
>>>> No idea. Looks like out of memory.
>>>
>>> I also think so.
>>> I look at the task manager.
>>> The memory that lilypond.exe uses is increased rapidly.
>>> Then, lilypond.exe crashes at about 2 GB.
>>>
>>> My Windows environment is 64-bit. The memory is quite larger than 2 GB.
>>> I think that something continues demanding a memory by an infinite loop.
>>> Then, lilyond.exe crashes, when the 32-bit process memory limit is exceeded.
>>
>> My guess would have been that garbage collection is broken on the
>> platform, but even without collecting garbage, I should think that 2GB
>> should be sufficient for getting a small file like that compiled.
>
> I turned off compilation optimization of mingw::lilypond as follows.
> https://github.com/trueroad/gub/commit/1a6bc45fc00fa326270f2be40a5f588083e9db75
>
> As a result, std::bad_alloc didn't occur any more.
> But it was the following error.
>
> ```
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>lilypond test.ly
> GNU LilyPond 2.19.16
> Processing `test.ly'
> Parsing...
> test.ly:1: warning: no \version statement found, please add
>
> \version "2.19.16"
>
> for future compatibility
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `test.ps'...
> Converting to `./test.pdf'...
> warning: `(gs -q -dNOSAFER -dDEVICEWIDTHPOINTS=-0.00
> -dDEVICEHEIGHTPOINTS=-0.00
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
> -sOutputFile
> =./test.pdf -c.setpdfwrite -ftest.ps)' failed (1)
>
> programming error: Parsed object should be dead: #<Grob NoteSpacing >
> continuing, cross fingers
> programming error: Parsed object should be dead: #<Prob: paper-system C++:
> Prob(
> (Y-offset . 1.0) (system-grob . #<Grob System >) (staff-refpoint-extent
> -3.776 .
> -3.776) (last-in-score . #t) (page-turn-penalty) (page-break-penalty)
> (page-tur
> n-permission . allow) (page-break-permission . allow) (vertical-skylines .
> #<Sky
> line_pair>) (stencil . #<Stencil>))() >
>
> continuing, cross fingers
> fatal error: failed files: "test.ly"
>
> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>
> ```
>
> test.ps lilypond generated was broken.
> test.pdf was also broken of course.
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when optimization was turned on.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
