Re: broken doc build (orchestra.ly)

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
> [Bisection]
>
>>> Commit c1d7bc2217462a63bf5c5c6d6f6df5cb00099180
>>> Author: David Kastrup <address@hidden>
>>> Date:   Tue May 3 19:11:15 2016 +0200
>>>
>>>     Issue 4842/6: Don't special-case Scheme_engraver's acknowledgers
>>>
>>>
>>> /build/Documentation/ly-examples/orchestra.preview.log
>>> ===============================================
>>> Changing working directory to: `./out-www'
>>> Processing `/home/knut/sources/lily/Documentation/ly-examples/orchestra.ly'
>>> Parsing...
>>> Interpreting music...ERROR: Wrong type (expecting exact integer): (x y)
>>
>> Oh wow.  The expression with the wrong type is something completely
>> different here.  That makes it likely that we are dealing with an
>> expression that has been garbage-collected prematurely and is
>> overwritten with something else randomly before use.
>
> So yes, I think there is a problem in that commit regarding
> garbage-protecting a Scheme_engraver's acknowledgers.

Nope, there wasn't.  If at all, it is sort of a timing problem where the
derived_mark of a Scheme_engraver might be called before the type is
fully initialized or it is _not_ called until it is fully initialized
and fails to protect the partially constructed type.

> But: I don't think that orchestra.ly even uses a Scheme engraver, and
> the problem would not hit before such an engraver is actually
> instantiated in some context.  Very weird.

Can you run this under a debugger and place a breakpoint on
Scheme_engraver::init_from_scheme or just write abort(); as its first
line?  I want to know whether the problem is triggered _without_
creating a Scheme_engraver.  Or whether I just did not figure out how a
Scheme_engraver comes into play here.

-- 
David Kastrup