Re: Regtests crashing?
Keith OHara schreef op di 15-03-2011 om 03:26 [+]: > Neil Puttock gmail.com> writes: > The obvious fix allows make test-baseline to succeed, and could only affect > midi, so I pushed it. cc: to Jan in case the 'obvious' was not the intent. That's the right fix, thanks! Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests crashing?
Neil Puttock gmail.com> writes: > > Interesting. I was on the right track, but it appears to be deleting > something which has already been deleted: > > Audio_staff* > Staff_performer::new_audio_staff (string voice) [..] > > In baerenreiter-sarabande.ly, there's an unnamed voice (I'm not sure > where it is though :) which gets a track name of ":". Since the above > code doesn't create a new name_, it's announced as the previous > Audio_text. Thus there are two identical pointers added to > Performance::audio_elements_, the second of which junk_pointers () > attempts to delete after it's already gone. > A simple revert of the relevant commit fails because of intermingled changes to midi2ly. The obvious fix allows make test-baseline to succeed, and could only affect midi, so I pushed it. cc: to Jan in case the 'obvious' was not the intent. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests crashing?
On 14 March 2011 23:26, m...@apollinemike.com wrote:
> backtrace from valgrind, also after balloon.ly
[snip]
Interesting. I was on the right track, but it appears to be deleting
something which has already been deleted:
Audio_staff*
Staff_performer::new_audio_staff (string voice)
{
Audio_staff* audio_staff = new Audio_staff;
string track_name = context ()->id_string () + ":" + voice;
if (track_name != ":")
{
name_ = new Audio_text (Audio_text::TRACK_NAME, context ()->id_string ()
+ ":" + voice);
audio_staff->add_audio_item (name_);
}
announce_element (Audio_element_info (audio_staff, 0));
announce_element (Audio_element_info (name_, 0));
In baerenreiter-sarabande.ly, there's an unnamed voice (I'm not sure
where it is though :) which gets a track name of ":". Since the above
code doesn't create a new name_, it's announced as the previous
Audio_text. Thus there are two identical pointers added to
Performance::audio_elements_, the second of which junk_pointers ()
attempts to delete after it's already gone.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests crashing?
On Mar 14, 2011, at 6:41 PM, Neil Puttock wrote: > On 14 March 2011 22:19, Graham Percival wrote: >> On Mon, Mar 14, 2011 at 03:27:06PM -0400, m...@apollinemike.com wrote: >>> I am having trouble getting a clean baseline from the regtests, and trying >>> to grep the culprit is, for some odd reason, taking several minutes. Could >>> someone please run the regtests on the current master and confirm if there >>> is an issue? >> >> I noticed this in the afternoon -- from a clean build dir -- but I >> haven't managed to track it down yet. Something definitely fishy, >> though. > > It's something to do with Jan's midi changes AFAICT. The only way I > could debug was to run all the regtests through GDB: this stops with a > segfault after completing balloon.ly, but it seems to be the previous > test (baerenreiter-sarabande.ly) which triggers the crash (at least, > that's my guess since it's the first test to produce a .midi file). > > Here's a backtrace: > > (gdb) bt > #0 0x0031 in ?? () > #1 0x005ed5d8 in del::operator() > (this=0x7fff28a0, x=0x1b513d0) at > ../flower/include/std-vector.hh:241 > #2 0x005ed091 in > std::for_each<__gnu_cxx::__normal_iterator std::__flower_vector > >> , del > (__first=..., __last=..., __f=...) >at /usr/include/c++/4.4/bits/stl_algo.h:4200 > #3 0x005ecd67 in junk_pointers (v=...) at > ../flower/include/std-vector.hh:251 > #4 0x005ec3d2 in Performance::~Performance (this=0x1b41110, > __in_chrg=) at performance.cc:45 > #5 0x0057611d in Music_output::free_smob (ses=0x71563f40) > at music-output.cc:43 > #6 0x7793c4aa in scm_i_sweep_card () from /usr/lib/libguile.so.17 > #7 0x7793aab3 in scm_i_sweep_some_cards () from > /usr/lib/libguile.so.17 > #8 0x7793ac10 in scm_i_sweep_segment () from /usr/lib/libguile.so.17 > #9 0x7793acd0 in scm_i_sweep_all_segments () from > /usr/lib/libguile.so.17 > #10 0x77939887 in scm_i_gc () from /usr/lib/libguile.so.17 > #11 0x779399ca in scm_gc () from /usr/lib/libguile.so.17 > > It might be the case that the destructor for Performance is trying to > delete a pointer to an Audio_element which wasn't allocated via `new'. > > Cheers, > Neil > backtrace from valgrind, also after balloon.ly ==28715==at 0x1001A5CBB: Performance::~Performance() (in /usr/local/bin/lilypond) ==28715==by 0x10013F402: Music_output::free_smob(scm_unused_struct*) (in /usr/local/bin/lilypond) ==28715==by 0x1009C96EA: scm_i_sweep_card (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7A29: scm_i_sweep_some_cards (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7C58: scm_i_sweep_segment (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7CF7: scm_i_sweep_all_segments (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C5C88: scm_i_gc (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C5A6B: scm_gc (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009B2734: ceval (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009AE31F: ceval (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009ADC10: scm_eval_body (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009B628E: call_closure_1 (in /usr/local/lib/libguile.17.dylib) ==28715== Address 0x1107e8cc0 is 0 bytes inside a block of size 32 free'd ==28715==at 0x100720B11: operator delete(void*) (vg_replace_malloc.c:387) ==28715==by 0x100028594: Audio_text::~Audio_text() (in /usr/local/bin/lilypond) ==28715==by 0x1001A5CC0: Performance::~Performance() (in /usr/local/bin/lilypond) ==28715==by 0x10013F402: Music_output::free_smob(scm_unused_struct*) (in /usr/local/bin/lilypond) ==28715==by 0x1009C96EA: scm_i_sweep_card (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7A29: scm_i_sweep_some_cards (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7C58: scm_i_sweep_segment (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7CF7: scm_i_sweep_all_segments (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C5C88: scm_i_gc (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C5A6B: scm_gc (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009B2734: ceval (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009AE31F: ceval (in /usr/local/lib/libguile.17.dylib) ==28715== ==28715== Invalid write of size 8 ==28715==at 0x10002714B: Audio_element::~Audio_element() (in /usr/local/bin/lilypond) ==28715==by 0x1001A5CC0: Performance::~Performance() (in /usr/local/bin/lilypond) ==28715==by 0x10013F402: Music_output::free_smob(scm_unused_struct*) (in /usr/local/bin/lilypond) ==28715==by 0x1009C96EA: scm_i_sweep_card (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7A29: scm_i_sweep_some_cards (in /usr/local/lib/libguile.17.dylib) ==28715==by 0x1009C7C58: scm_i_sweep_segment (in /usr/local/lib/libguile.17.dylib) ==28715
Re: Regtests crashing?
On 14 March 2011 22:19, Graham Percival wrote: > On Mon, Mar 14, 2011 at 03:27:06PM -0400, m...@apollinemike.com wrote: >> I am having trouble getting a clean baseline from the regtests, and trying >> to grep the culprit is, for some odd reason, taking several minutes. Could >> someone please run the regtests on the current master and confirm if there >> is an issue? > > I noticed this in the afternoon -- from a clean build dir -- but I > haven't managed to track it down yet. Something definitely fishy, > though. It's something to do with Jan's midi changes AFAICT. The only way I could debug was to run all the regtests through GDB: this stops with a segfault after completing balloon.ly, but it seems to be the previous test (baerenreiter-sarabande.ly) which triggers the crash (at least, that's my guess since it's the first test to produce a .midi file). Here's a backtrace: (gdb) bt #0 0x0031 in ?? () #1 0x005ed5d8 in del::operator() (this=0x7fff28a0, x=0x1b513d0) at ../flower/include/std-vector.hh:241 #2 0x005ed091 in std::for_each<__gnu_cxx::__normal_iterator > >, del > (__first=..., __last=..., __f=...) at /usr/include/c++/4.4/bits/stl_algo.h:4200 #3 0x005ecd67 in junk_pointers (v=...) at ../flower/include/std-vector.hh:251 #4 0x005ec3d2 in Performance::~Performance (this=0x1b41110, __in_chrg=) at performance.cc:45 #5 0x0057611d in Music_output::free_smob (ses=0x71563f40) at music-output.cc:43 #6 0x7793c4aa in scm_i_sweep_card () from /usr/lib/libguile.so.17 #7 0x7793aab3 in scm_i_sweep_some_cards () from /usr/lib/libguile.so.17 #8 0x7793ac10 in scm_i_sweep_segment () from /usr/lib/libguile.so.17 #9 0x7793acd0 in scm_i_sweep_all_segments () from /usr/lib/libguile.so.17 #10 0x77939887 in scm_i_gc () from /usr/lib/libguile.so.17 #11 0x779399ca in scm_gc () from /usr/lib/libguile.so.17 It might be the case that the destructor for Performance is trying to delete a pointer to an Audio_element which wasn't allocated via `new'. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regtests crashing?
On Mon, Mar 14, 2011 at 03:27:06PM -0400, m...@apollinemike.com wrote: > I am having trouble getting a clean baseline from the regtests, and trying to > grep the culprit is, for some odd reason, taking several minutes. Could > someone please run the regtests on the current master and confirm if there is > an issue? I noticed this in the afternoon -- from a clean build dir -- but I haven't managed to track it down yet. Something definitely fishy, though. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Regtests crashing?
Hey all, I am having trouble getting a clean baseline from the regtests, and trying to grep the culprit is, for some odd reason, taking several minutes. Could someone please run the regtests on the current master and confirm if there is an issue? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
