Re: GUB and mpfr/mpc

[Masamichi HOSODA]

>> Masamichi HOSODA <address@hidden> writes:
>> 
>>>> Masamichi HOSODA <address@hidden> 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.