Re: Issue 818 in lilypond: Bus error when adding Instrument_name_engraver to StaffGroup and outputting MIDI.

[Phil Holmes]

<address@hidden> wrote in message 
news:address@hidden
> 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