Re: volleyball issue 1336

[Carl Sorensen]

On 11/30/10 4:24 AM, "Graham Percival" <address@hidden> wrote:

> This is an attempt to collaboratively solve issue 1336.  (that said,
> if anybody can jump in and solve it instantly with a patch, go right
> ahead!  if this issue is solved, we'll just pick another one)
> http://code.google.com/p/lilypond/issues/detail?id=1336
> 
> There is a theory about why this happens, from Neil:
>> It looks to me like the MultiMeasureRest has invalid bounds when cloned, so
>> the cloned object is NULL when the MultiMeasureRestNumber is aligned (the
>> parent object no longer exists)
> 
> Can anybody think of a way to test this theory?  i.e. I'm not asking
> how to stop this from happening.  I'm not even asking for solid
> evidence that this is, in fact, happening.  I'm just asking how we
> could *begin* the *attempt* to gather such evidence.

I've identified that it is in fact the MultiMeasureRestNumber that is
causing the problem.  My version of your patch that sets the offset to zero
rather than exiting results in the MMRNumber showing up at the far left of
the page.

The "invalid bounds" part of it is demonstrated in the error message when
bad.ly is run:

bad.ly:8:2: programming error: Spanner `MultiMeasureRest' is not fully
contained in parent spanner. Ignoring orphaned part

This error message comes from lily/spanner.cc.  There is a method in
lily/spanner.cc called clone:

 29 Grob *
 30 Spanner::clone () const
 31 {
 32   return new Spanner (*this);
 33 }

The clone method is called from Spanner::do_break_processing

60           else if (bound->get_system ())
 61             {
 62               Spanner *span = dynamic_cast<Spanner *> (clone ());
 63               span->set_bound (LEFT, bound);
 64               span->set_bound (RIGHT, bound);
 65 
 66               assert (span->get_system ());
 67               span->get_system ()->typeset_grob (span);
 68               broken_intos_.push_back (span);
 69             }

Also, the clone method would be called if the error message weren't issued:

113           bool ok = parent_rank_slice.contains (bounds[LEFT]->get_column
()-    >get_rank ());
114           ok = ok && parent_rank_slice.contains
(bounds[RIGHT]->get_column (    )->get_rank ());
115 
116           if (!ok)
117             {
118               programming_error (to_string ("Spanner `%s' is not fully
conta    ined in parent spanner. Ignoring orphaned part",
119                                             name ().c_str ()));
120               continue;
121             }
122 
123 
124           Spanner *span = dynamic_cast<Spanner *> (clone ());
125           span->set_bound (LEFT, bounds[LEFT]);
126           span->set_bound (RIGHT, bounds[RIGHT]);


I actually think this may be a profitable place to investigate.



My attempts have taken a slightly different tack.  I'm looking up the
backtrace, trying to see if I can do something with understanding the
delayed evaluation chain (frames 4-6).  Going above the delayed evaluation,
I get to get_offset and relative_coordinate, both in lily/grob.cc.

Looking in relative_coordinate, I see

300 Real
301 Grob::relative_coordinate (Grob const *refp, Axis a) const
302 {
303   /* eaa - hmmm, should we do a programming_error() here? */
304   if ((this == NULL) || (refp == this))
305     return 0.0;
306 
307   /* We catch PARENT_L_ == nil case with this, but we crash if we did
308      not ask for the absolute coordinate (ie. REFP == nil.)  */
309   Real off = get_offset (a);
310   if (refp == dim_cache_[a].parent_)
311     return off;
312 
313   off += dim_cache_[a].parent_->relative_coordinate (refp, a);
314 
315   return off;
316 }


This looks like a promising place to investigate some more, because I don't
really see that we "catch PARENT_L_ == nil case".  But I haven't yet had the
time to investigate this.

HTH,

Carl