Menu
▾
▴
#2030 2.14.2, dynamic cast crash introduced in commit 6f6369c0
Originally created by: *anonymous
Originally created by: pkx1...@gmail.com
Hello!
Lilypond 2.14.2 and the current revision from stable/2.14 crash on this
file:
\version "2.14.2"
\score {
\new PianoStaff <<
\new Staff = "right" { \change Staff="left" }
\new Staff = "left" { s1 }
>>
\layout { }
}
Bisection finds that the regression was introduced on the stable branch
(!!!) by this commit:
[r6f6369c0e143402296e51708fddb8e3cc875dd09] is the first bad commit
commit [r6f6369c0e143402296e51708fddb8e3cc875dd09]
Author: Joe Neeman <joeneeman@gmail.com>
Date: Fri May 27 18:57:16 2011 +0300
Emit not-quite-cross-staff beams in the right context.
This is related to 1043 and possibly other bugs. Previously,
if a staff change happened immediately after the termination of
an auto-engraved cross-staff beam, then the beam was parented
to the wrong staff. Now, every beam is parented to the context
in which it began.
:040000 040000 [r9fb6f0e342f2e64ca9b56c2d6e0d02556895e983]
[rf248a9e0cc58847fddc0ad98e7eb839b8d3dbc60] M lily
And that's what gdb shows for the current stable/2.14:
GNU LilyPond 2.14.2
Processing `bad.ly'
Parsing...
Interpreting music...
Program received signal SIGSEGV, Segmentation fault.
__cxxabiv1::__dynamic_cast (src_ptr=0x7fffffffffff, src_type=0xae1870,
dst_type=0xad9ea0, src2dst=-1)
at ../../../../libstdc++-v3/libsupc++/dyncast.cc:51 51 const
void *vtable = *static_cast <const void *const *> (src_ptr); (gdb) up
#1 0x000000000054cef4 in Engraver_group::announce_grob (this=0xc8c840,
info=...) at engraver-group.cc:83 83 : 0; (gdb) l
78 }
79
80 Engraver_group *dad_eng
81 = dad_con
82 ? dynamic_cast<Engraver_group *> (dad_con->implementation
()) 83 : 0;
84
85 if (dad_eng)
86 dad_eng->announce_grob (info);
87 }
(gdb)
dad_con was introduced by the commit in question. It looks like
dad_con->implementation is of a wrong type. I hope it should be easy
to fix for somebody who knows C++.
Discussion
Originally posted by: plros...@gmail.com
I can reproduce the issue on a Fedora 16 system, but not on a Fedora 15 system. On the later, I get:
GNU LilyPond 2.14.2
Processing `test.ly'
Parsing...
Interpreting music...
warning: Change_iterator::process (): Staff = `right':
test.ly:4:26: warning: cannot change `Staff' to `left': not changing to same context type: Staff
\new Staff = "right" {
\change Staff="left" }
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
Converting to `./test.pdf'...
success: Compilation successfully completed
That's what I would get with the patch in question (6f6369c0) reverted.
Originally posted by: plros...@gmail.com
The bug as it's entered is bogus. It turns out lilypond has an issue with the build system. The incremental make is not reliable (another bug!). Only "make clean && make" can be relied upon. With the correctly built lilypond this example doesn't cause a crash. I simplified my example too much. Here's the minimal lilypond file that crashes even correctly built lilypond:
\version "2.14.2"
\score {
<<
\new Staff = right { [r4] \change Staff=left [r8] b b b \change Staff=right s }
\new Staff = left { [r4] }
>>
\layout { }
}
And that's where the crash happens:
GNU LilyPond 2.14.2
Processing `bad.ly'
Parsing...
Interpreting music...
Program received signal SIGSEGV, Segmentation fault.
0x000000000052febc in Context::get_parent_context (this=0x0) at context.cc:688
688 return daddy_context_;
(gdb) where
#0 0x000000000052febc in Context::get_parent_context (this=0x0) at context.cc:688
#1 0x000000000054cd6f in Engraver_group::announce_grob (this=0xdcb970, info=...) at engraver-group.cc:73
#2 0x000000000054ce14 in Engraver_group::announce_grob (this=0xddb9b0, info=...) at engraver-group.cc:86
#3 0x000000000054f160 in Engraver::announce_grob (this=0xdc8890, inf=...) at engraver.cc:40
#4 0x00000000004b4ac9 in Auto_beam_engraver::create_beam (this=0xdc8890) at auto-beam-engraver.cc:225
#5 0x00000000004b4edc in Auto_beam_engraver::end_beam (this=0xdc8890) at auto-beam-engraver.cc:272
#6 0x00000000004b4304 in Auto_beam_engraver::process_music (this=0xdc8890) at auto-beam-engraver.cc:130
#7 0x0000000000743261 in Translator_method_binding::invoke (this=0xdca950) at ./include/translator-group.hh:46
#8 0x0000000000742b3b in Translator_group::precomputed_translator_foreach (this=0xddb9e0, idx=PROCESS_MUSIC)
at translator-group.cc:325
#9 0x0000000000742706 in precomputed_recurse_over_translators (c=0xddab60, idx=PROCESS_MUSIC, dir=UP)
at translator-group.cc:256
#10 0x00000000007426c8 in precomputed_recurse_over_translators (c=0xdc0170, idx=PROCESS_MUSIC, dir=UP)
at translator-group.cc:252
#11 0x00000000007426c8 in precomputed_recurse_over_translators (c=0xc8dab0, idx=PROCESS_MUSIC, dir=UP)
at translator-group.cc:252
#12 0x000000000068eb4f in Score_engraver::one_time_step (this=0xc8e600) at score-engraver.cc:151
#13 0x000000000068e725 in Score_engraver::one_time_step_callback (self=0xc8e600, ev=0x7fffef0b82c0)
at score-engraver.cc:145
#14 0x00000000005bf2c2 in Listener::listen (this=0xc8f2e0, ev=0x7fffef0b82c0) at listener.cc:43
#15 0x0000000000539697 in Dispatcher::dispatch (this=0xc8d160, sev=0x7fffef0b82c0) at dispatcher.cc:150
#16 0x0000000000538ae8 in Dispatcher::broadcast (this=0xc8d160, ev=0xdf8ab0) at dispatcher.cc:173
#17 0x000000000052efd3 in Context::internal_send_stream_event (this=0xc8c998, type=0x7ffff10ad840, origin=0x0, props=
0x7fffffff8fc0) at context.cc:461
#18 0x0000000000574a00 in Global_context::run_iterator_on_me (this=0xc8c910, iter=0xc8d660) at global-context.cc:170
#19 0x00000000005732b7 in ly_interpret_music_expression (mus=0x7fffef1ef8f0, ctx=0x7fffef12d490)
at global-context-scheme.cc:119
#20 0x0000000000573885 in ly_run_translator (mus=0x7fffef1ef8f0, output_def=0x7fffef1486e0)
at global-context-scheme.cc:147
#21 0x0000000000693f93 in Score::book_rendering (this=0xda6f30, layoutbook=0xda7a50, default_def=0xd5b730)
at score.cc:157
#22 0x00000000004fa2ea in Book::process_score (this=0xda5ba0, s=0x7fffef148750, output_paper_book=0xda79e0, layout=
0xd5b730) at book.cc:236
#23 0x00000000004fa65a in Book::process (this=0xda5ba0, default_paper=0xd59f50, default_layout=0xd5b730, parent_part=
0x0) at book.cc:302
#24 0x00000000004fa1a5 in Book::process (this=0xda5ba0, default_paper=0xd59f50, default_layout=0xd5b730) at book.cc:207
#25 0x00000000004f7877 in ly_book_process (book_smob=0x7fffef168f30, default_paper=0x7fffef408170, default_layout=
0x7fffef30b3b0, output=0x7ffff0e32ea0) at book-scheme.cc:76
#26 0x000000364ea4f576 in ceval (x=<optimized out>, env=0x7fffef168470) at eval.c:4382
#27 0x0000000000653b56 in internal_ly_parse_scm (ps=0x7fffffff9620) at parse-scm.cc:76
#28 0x0000000000653d6a in ly_parse_scm (s=
0xc7d14d "(let ((book-handler (if (defined? 'default-toplevel-book-handler)\n", ' ' <repeats 25 times>, "default-toplevel-book-handler\n", ' ' <repeats 25 times>, "toplevel-book-handler)))\n (cond ((pair? toplevel-boo"..., n=
0x7fffffff9ab0, i=..., safe=false, parser=0xc7ae70) at parse-scm.cc:139
#29 0x000000000076363d in Lily_lexer::yylex (this=0xc7aef0) at lexer.ll:351
#30 0x00000000007771e5 in yylex (s=0x7fffffffc4d0, loc=0x7fffffffba40, v=0xc7ae70) at parser.yy:2790
#31 0x0000000000769a92 in yyparse (my_lily_parser=0xc7ae70) at out/parser.cc:2507
#32 0x000000000077628a in Lily_parser::do_yyparse (this=0xc7ae70) at parser.yy:2563
#33 0x00000000005b6ffa in Lily_parser::parse_file (this=0xc7ae70, init="init.ly", name="bad.ly", out_name="bad")
at lily-parser.cc:121
#34 0x00000000005b2a65 in ly_parse_file (name=0x7ffff0e9ede0) at lily-parser-scheme.cc:123
#35 0x000000364ea4fda2 in ceval (x=<optimized out>, env=0x7fffec8b6740) at eval.c:4232
#36 0x000000364eaa4393 in scm_c_catch (tag=0x7ffff0eeabe0, body=0x364eaa4150 <scm_body_thunk>, body_data=
0x7fffffffd990, handler=0x364eaa4140 <scm_handle_by_proc>, handler_data=0x7fffffffd988, pre_unwind_handler=0,
pre_unwind_handler_data=0x7fffffffd980) at throw.c:203
#37 0x000000364eaa459e in scm_catch_with_pre_unwind_handler (key=<optimized out>, thunk=<optimized out>, handler=
0x7fffec8b67d0, pre_unwind_handler=0x204) at throw.c:587
#38 0x000000364ea4f576 in ceval (x=<optimized out>, env=0x7fffec8b6890) at eval.c:4382
#39 0x000000364ea4f97c in ceval (x=0x7fffecc178c0, env=0x7fffec8b6940) at eval.c:3397
#40 0x00007fffefca5fc1 in scm_srfi1_for_each (proc=0x7fffec8b8f80, arg1=0x7fffecc86740, args=0x404) at srfi-1.c:1516
#41 0x000000364ea4ff9c in ceval (x=<optimized out>, env=0x7fffecc86c20) at eval.c:4367
#42 0x000000364ea4f97c in ceval (x=0x7fffecc16020, env=0x7fffecc86c20) at eval.c:3397
#43 0x000000364ea50ae3 in ceval (x=0x7fffecc86a70, env=0x7fffecc867f0) at eval.c:3648
#44 0x00000000005cbdb4 in main_with_guile () at main.cc:437
#45 0x000000364ea66f6f in invoke_main_func (body_data=0x7fffffffdff0) at init.c:367
#46 0x000000364ea3da9a in c_body (d=0x7fffffffdf90) at continuations.c:349
#47 0x000000364eaa4393 in scm_c_catch (tag=0x104, body=0x364ea3da90 <c_body>, body_data=0x7fffffffdf90, handler=
0x364ea3dab0 <c_handler>, handler_data=0x7fffffffdf90, pre_unwind_handler=
0x364eaa49c0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:203
#48 0x000000364ea3e027 in scm_i_with_continuation_barrier (body=0x364ea3da90 <c_body>, body_data=0x7fffffffdf90,
handler=0x364ea3dab0 <c_handler>, handler_data=0x7fffffffdf90, pre_unwind_handler=<optimized out>,
pre_unwind_handler_data=<optimized out>) at continuations.c:325
#49 0x000000364ea3e0c0 in scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>)
at continuations.c:367
#50 0x000000364eaa2844 in scm_i_with_guile_and_parent (func=0x364ea66f50 <invoke_main_func>, data=0x7fffffffdff0,
parent=<optimized out>) at threads.c:733
#51 0x000000364ea67025 in scm_boot_guile (argc=<optimized out>, argv=<optimized out>, main_func=<optimized out>,
closure=<optimized out>) at init.c:350
#52 0x00000000005cd0c8 in main (argc=2, argv=0x7fffffffe158, envp=0x7fffffffe170) at main.cc:632
(gdb) up
#1 0x000000000054cd6f in Engraver_group::announce_grob (this=0xdcb970, info=...) at engraver-group.cc:73
73 Context *dad_con = context_->get_parent_context ();
(gdb) up
#2 0x000000000054ce14 in Engraver_group::announce_grob (this=0xddb9b0, info=...) at engraver-group.cc:86
86 dad_eng->announce_grob (info);
(gdb) p dad_eng->context_
$1 = (Context *) 0x0
(gdb) p dad_eng
$2 = (Engraver_group *) 0xdcb970
Originally posted by: gra...@percival-music.ca
hmm, interesting. BTW, "make clean" is not reliable either. In my mind, the only reliable thing is:
- completely remove the build directory (we strong suggest doing out-of-tree builds for this reason)
- build from scratch, starting from configure.
This still doesn't work 2-4 times a year when it requires running ./autogen.sh --noconfigure again, but other than that it's a pretty good recipe.
Originally posted by: plros...@gmail.com
The fix is to backport 9ff88d12 from master. The patch is attached. Considering that it's a crash in the latest stable release, it would be nice to see another stable release.
Originally posted by: k-ohara5...@oco.net
Let's point this to issue 1800, then, and mark the fixed version, and even though no more back ports are planned, a backport tag won't hurt anybody.
Not knowing what "dynamic_cast" does, I'm not sure if it is exactly a duplicate of 1800.
Labels: fixed_2_15_9 backport
Status: Fixed
Originally posted by: plros...@gmail.com
This ticket is misnamed. The crash is not in dynamic_cast. It was in dynamic_cast because I miscompiled lilypond. Once I started making full rebuilds, I had to redo my simplification, which led me to a file similar to that in bug 1800. And the crash was because on the context going away after Auto_beam_engraver::begin_beam() was called, but before Auto_beam_engraver::create_beam().
Originally posted by: colingh...@gmail.com
To verify this I used the sample code submitted by plroskin in Comment #2
\version "2.14.2"
\score {
<<
\new Staff = right { [r4] \change Staff=left [r8] b b b \change Staff=right s }
\new Staff = left { [r4] }
>>
\layout { }
}
With 2.14.2 the compilation fails with a Segmentation fault. With 2.15.22-1 the Lilypond source compiles successfully. A preview of the result is attached.
So this is verified for 2.15.22 on Ubuntu 10.04.
Status: Verified
Originally posted by: plros...@gmail.com
The trunk (2.15.x) was fixed long ago. The problem only exists in 2.14.x and the fix would be to apply my patch to the stable-2.14 branch and release 2.14.3 from it. I believe it's a reasonable and simple thing to do. There is already one commit in stable-2.14 after 2.14.2.
Originally posted by: dak@gnu.org
If we chose to do 2.14.3, the fix for Issue 1997 would likely have to go in as well, or we would be hearing from it...
Originally posted by: gra...@percival-music.ca
Yes, anything is "reasonable and simple" when it's somebody else doing the work.
I am not certain that GUB can still build 2.14. If you can build the 2.14.3 binaries with GUB with absolutely no problems, then I'll consider making a 2.14.3 release when I'm back in Glasgow. But no promises.
As far as I'm concerned, asking somebody else to test a release before I'll even consider it is "reasonable and simple".
Originally posted by: dak@gnu.org
Backport label removed as we will not make another 2.14 release.
Labels: -backport