Re: looking for help debugging a "return code 1 error"

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> A little more that might help:
>
> 1. My skeleton score has a bunch of partcombine-d staves (all empty),
> and a single vocal staff (with music).
>
> 2. The vocal staff uses David Nalesnik’s
> text-spanner-inner-texts. This works perfectly in the piano-vocal
> score of the same piece (i.e., without the partcombine-d instrumental
> staves).
>
> 3. If I comment out all partcombine-d content AND the
> text-spanner-inner-texts code, the score compiles without error. If I
> leave in the text-spanner-inner-texts code OR a few partcombine-d
> staves, the score compiles without error. Only if I try to have both
> the text-spanner-inner-texts code AND one or more partcombine-d staves
> does the compile fail.
>
> 4. The second last line of the log, e.g.,
>> ERROR: Wrong type (expecting exact integer): Timing
> changes depending on how much I’ve commented out or left in. The
> ‘Timing’ might say ‘DrumVoice’ or ‘Staff’ or ‘VaticanaVoice’, etc. I
> have not figured out a pattern.
>
> Thanks for any hints/help.

You have identified one tangible component likely involved with the
problem and you only mention it by name.  Even if only a single person
is interested in answering, the effort for him to dig up some version
possibly corresponding with the one you use will already be higher than
for you to just include what you are talking about.

It also sounds as if you are reasonably close to figuring out how to
create an actual minimal example using just the specified code and no
other includes.

The possibilities for tracking this down will be either staring at the
text-spanner-inner-texts source code until one notices something fishy,
or it will include debugging actual code.  The kind of
no-rhyme-no-reason behavior you describe looks like a problem involving
garbage collection.  That can not actually be triggered by Scheme code
alone without having some C++ code involved as well.

That makes it less likely that dry inspection without actual debugging
will uncover the problem.

The last lines of the traceback

 243: 13  [ly:book-process #<Book> #< Output_def> ...]
In unknown file:
   ?: 14* [# #]
   ?: 15* [# # #]
   ?: 16* [#<Callback0_wrapper> #<Translator Auto_beam_engraver >]

point to code likely introduced in version 2.19.55 as

commit 6d1c5d25389afa6dbbfb4722df3732e764cbbf2e
Author: David Kastrup <address@hidden>
Date:   Fri Jan 27 13:27:03 2017 +0100

    Issue 1375/1: Let Translator constructor take a Context argument
    
    This is the first step towards constructing rather than cloning translators
    when creating contexts.  On its own, it does not make sense, but the change
    is large and mostly mechanical, so keeping it separate from the actually
    difficult parts makes sense.

This has changed internal organization of translators including
protection of some translator internals.  David's work often has to mess
with internals (for lack of working interfaces allowing similar
extensions by regular means), so it may well be that it leaves them in a
state where the assumptions underlying the internal translator
organization are no longer met in a manner the current translator code
expects.

That's just guessing, of course.

-- 
David Kastrup