"Keith E OHara" <k-oh...@oco.net> writes:
> Invoking Lilypond individually for the .ly files also succeeds, so
> maybe this has something to do with compiling two input files, each
> setting volta repeats, in one session. Next time I have time, I
> suppose I should pull the candidate 2.18 stable branch and make sure
> there is no problem there.
>
> ===
> (gdb) bt
> #0 0x00000001 in ?? ()
> #1 0x080a863a in Sequential_iterator::run_always (this=0xf0482d8) at
> sequential-iterator.cc:268
> #2 0x080a863a in Sequential_iterator::run_always (this=0x10285b80) at
> sequential-iterator.cc:268
> #3 0x083264ba in Music_wrapper_iterator::run_always (this=0x103a8090)
> at music-wrapper-iterator.cc:87
> #4 0x083264ba in Music_wrapper_iterator::run_always (this=0x103853e8)
> at music-wrapper-iterator.cc:87
> #5 0x0836eef1 in Simultaneous_music_iterator::ok (this=0x105461a8) at
> simultaneous-music-iterator.cc:127
> #6 0x0815e2d8 in Global_context::run_iterator_on_me (this=0xfd77850,
> iter=0x105461a8) at global-context.cc:139
> #7 0x0834510a in ly_interpret_music_expression (mus=0xac3ab898,
> ctx=0xb750a840) at global-context-scheme.cc:118
This is a rather shallow coredump. Inside of the global simultanous
music, you have two Music wrappers (typically something like \new ... )
and two nested calls of Sequential_iterator::run_always.
Sequential_iterator::run_always is a virtual function, but here it has
not been overriden (or the core dump would show something else). The
code is just
bool
Sequential_iterator::run_always () const
{
return iter_ ? iter_->run_always () : false;
}
So one suspicion would be that iter_ points to a non-operative
iterator. Maybe set it to zero in
void
Sequential_iterator::do_quit ()
{
if (iter_)
iter_->quit ();
}
It should likely not be called or manipulated again. Of course, neither
should be Sequential_iterator::do_quit but maybe better safe than sorry?
There is also that the volta repeat engraver does not declare its input
property currentCommandColumn, but I'm not sure how much of a problem
that can be.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
