<lilyp...@googlecode.com> wrote in message
news:20-9567054385019064696-2135885824776537067-lilypond=googlecode....@googlecode.com...
Comment #20 on issue 818 by n.puttock: Bus error when adding
Instrument_name_engraver to StaffGroup and outputting MIDI.
http://code.google.com/p/lilypond/issues/detail?id=818
OK, a few more notes:
Translators of the wrong type (i.e., performers for an Engraver_group,
engravers for a Performer_group) must be filtered out if they're added to
a context via \with. This happens in
Translator_group::create_child_translator () here:
204 if (dynamic_cast<Engraver_group *> (g))
205 g->simple_trans_list_ = filter_performers (trans_list);
206 else if (dynamic_cast<Performer_group *> (g))
207 g->simple_trans_list_ = filter_engravers (trans_list);
Both filter_engravers () and filter_performers () use dynamic_cast to
check whether a translator in `trans_list' is of the type which should be
removed. In the case of the optimized builds which segfault, the casting
fails.
Simply adding debug output to display the filtered list of translators at
the end of filter_engravers () causes the dynamic_cast to work.
Why would optimizing cause RTTI failure?
I've had this sort of behaviour in the dim-and-distant with a compiler bug
on VMS. I was using 2 pointers pointing to the same memory location, and
changing the value with pointer 1 then reading it with pointer 2. The
optmiser didn't spot that and assumed the second value was unchanged.
Clearly, if the value pointed to had been a pointer itself, it could have
been uninitialised. Bu**er to spot, since under debug it was fine.
I'm betting there's an uninitialised pointer somewhere in there, but most of
the time (by luck) it doesn't point to an invalid location. But with some
compiler settings, on some OSes, it does.
--
Phil Holmes
Bug Squad
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
