lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with difficult bug


From: Neil Puttock
Subject: Re: Help with difficult bug
Date: Tue, 15 Dec 2009 22:53:21 +0000

2009/12/15 Carl Sorensen <address@hidden>:

> Everything compiles OK.  And it runs fine until I get into recheck_beam.
> Recheck_beam actually executes successfully, but an exception is thrown
> later, and the exception doesn't make sense to me when I use gdb.  Values
> are changed between the calling procedure and the called procedure in a way
> that makes no sense to me (see
> <http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00283.html> for
> more info).

Weird.  Though I get the exception thrown, the GDB output seems sane
here.  Perhaps it's a build enviroment issue?

> Any help would most gratefully appreciated.

Here's some debug outpu on my system:

#7  0x000000000046015d in std::__vector<Beam_rhythmic_element,
std::allocator<Beam_rhythmic_element> >::_M_range_check
(this=0xb25470, __n=1)
    at /usr/include/c++/4.4/bits/stl_vector.h:634
#8  0x000000000045fc77 in std::__vector<Beam_rhythmic_element,
std::allocator<Beam_rhythmic_element> >::at (this=0xb25470, __n=1)
    at /usr/include/c++/4.4/bits/stl_vector.h:670
#9  0x000000000045f763 in Beaming_pattern::beamlet_count (this=0xb25470, i=1,
    d=DOWN) at beaming-pattern.cc:245
#10 0x0000000000456f9f in Beam::set_beaming (me=0xb778f0, beaming=0xb25470)
    at beam.cc:1341
#11 0x00000000004306c3 in Auto_beam_engraver::typeset_beam (this=0xb64260)

The exception is thrown by at (), which performs boundary checking (unlike []).

#9  0x000000000045f763 in Beaming_pattern::beamlet_count (this=0xb25470, i=1,
    d=DOWN) at beaming-pattern.cc:245
245       return infos_.at (i).beam_count_drul_[d];
(gdb) p infos_.size ()
$2 = 1

As you can see here, at this point infos_ only contains one element,
so at (1) will fail.

(gdb) fr 10
#10 0x0000000000456f9f in Beam::set_beaming (me=0xb778f0, beaming=0xb25470)
    at beam.cc:1341
1341                  int count = beaming->beamlet_count (i, d);
(gdb) p stems.size ()
$9 = 2

Though we have two stems here, when i=1, we get an exception, so
somewhere there's a stem which hasn't been added; you can see this
happening in autobeam-test.ly if you amend
Beaming_pattern::beamlet_count () to prevent the exception being
thrown:

int
Beaming_pattern::beamlet_count (int i, Direction d) const
{
  return i < infos_.size ()
    ? infos_.at (i).beam_count_drul_[d]
    : 0;
}

The second note in the second bar looks like a crotchet, since there's
no beam to attach it to the first note.

Here's the problem area inside recheck_beam ():

 for (vsize k = 0; k<i; k++)
            {
              beam_count = max (grouping_->beamlet_count (k, LEFT),
                                grouping_->beamlet_count (k, RIGHT));

              new_grouping_->add_stem (grouping_->start_moment (k),
                                       beam_count,
                                       grouping_->invisibility (k));
            }

If k < i, then add_stem () only adds one stem to new_grouping_,
whereas it should add another.  It should be safe for the loop to run
until k < i + 1 if the outer loop stops before i = stems_.size - 1:

for (vsize k = 0; k < i + 1; k++)

Regards,
Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]