Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA <address@hidden> writes:

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

I need more elements from the backtrace.  The problem most likely is
that the Skyline is destructed before work with it is finished, and that
means that somewhere in the call chain the Skyline is not maintained in
a manner where the Lisp Garbage collector will consider it as still in
use.

So internal_merge_skyline is likely only the place where things blow up,
but the actual cause will be further up in the call chain.

-- 
David Kastrup