Re: GUB and mpfr/mpc

[Masamichi HOSODA]

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

>> In freebsd-x86, gs fails as follows.
>> (I tested this on 64bit FreeBSD. Perhaps it may succeed on 32bit FreeBSD.)
>>
>> ```
>> $ cat test.ly
>> { c d e f g a b }
>>
>> $ ./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 -dSAFER -dDEVICEWIDTHPOINTS=595.28 
>> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
>> -r1200 -sDEVICE=pdfwrite -sOutputFile=./test.pdf -c.setpdfwrite -ftest.ps)' 
>> failed (139)
>>
>> fatal error: failed files: "test.ly"
> 
> That's a SIGSEGV.  Not something that a GhostScript executable should be
> throwing.  Could it be that the 64-bit cross compilation causes
> problems?

I tried on 32-bit FreeBSD.
The result was just similar.
I tried to execute gs directly.
Then Segmentation fault (core dumped) happened.

linux-x86 binary that I built seems no problem.
I think that it's no problem even if 32-bit binary
is cross compiled by the 64-bit environment.