Re: broken doc build (orchestra.ly)

[David Kastrup]

Knut Petersen <address@hidden> writes:

> Am 20.05.2016 um 17:27 schrieb David Kastrup:
>> David Kastrup <address@hidden> writes:
>>
>>> 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.
>>>
>
> Back at the PC again.
>
> lilypond 0e00ce29:
> ============
>
> make doc succeeds.
>
> lilypond c1d7bc22:

What about current master?  More exactly, did

56a1519b44d1a0a8500c43236ae644053cc1f25b

make a difference?

> "valgrind -v --track-origins=yes
> /home/knut/sources/lily/build/out/bin/lilypond -dpreview -ddebug
> -dresolution=150 -o ./out-www
> /home/knut/sources/lily/Documentation/ly-examples/orchestra.ly" fails
> 10 out of 10 times.
>
> lilypond c1d7bc22 with "abort();" at start of
> Scheme_engraver::init_from_scheme succeeds if called from bash prompt
> and fails with valgrind again.

Makes little enough sense to me.  At any rate, if the changed code does
not even get called, it would seem that rather the change in memory
layout might be responsible for triggering the problem.  I'll try to go
through the code with a fine comb and see whether I can find anything
that might make a difference when no Scheme_engraver is actually created
(which should correspond to init_from_scheme not being called).

> "-ddebug" does not work as lilypond tells me that there is no internal
> option named debug ;-)

Uh, -dverbose it was.

> valgrind logs of both versions differ a lot, but they are pretty
> big. Shall I send them to the list? I think it could be a good idea to
> look at those places that differ ...

I'm not sure.  valgrind output for code using a conservative garbage
collector tends to be of quite limited usefulness.

-- 
David Kastrup