lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUB and mpfr/mpc


From: Masamichi HOSODA
Subject: Re: GUB and mpfr/mpc
Date: Tue, 02 Dec 2014 23:31:43 +0900 (JST)

>>> 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.
>>
>> For both of bad_alloc prevented and optimization,
>> I tried the following setting.
>> Only one file (lily/skyline.cc) optimization is disabled
>> and all other files optimization is enabled.
> 
> Do you have a backtrace that might give us some more clue about where
> lily/skyline.cc has a problem?
> 
> I thought that I had at one time proposed something to be changed (as
> part of some issue?) order to deal with possible memory corruption, but
> a quick look through the log messages does not turn up either a commit
> from me or a commit message ringing a bell.

I turned off optimization to get correct backtrace,
but bad_alloc didn't occur.
Therefore I could get only incomplete backtrace.

It seems that push_back in Skyline::internal_merge_skyline throws bad_alloc.
I think the problem is Skyline::internal_merge_skyline
and/or first_intersection.

Skyline::internal_merge_skyline has a while loop with push_back.
I think that the loop termination condition may break by optimization.

So, I tried to disable optimization only not one file whole, but one function.

In the case of Skyline::internal_merge_skyline, the result was bad_alloc.
In the case of first_intersection,
the result was that correct PDF was generated.

The source tree when succeeding, is as follows.
https://github.com/trueroad/gub/commit/5e63dbde436bd3fca154557672394987c8d2e385

Masamichi Hosoda



reply via email to

[Prev in Thread] Current Thread [Next in Thread]