Menu
▾
▴
1 Attachments
#1997 segfault in tablature-negative-fret.ly
Originally created by: *anonymous
Originally created by: percival.music.ca@gmail.com
Originally owned by: dak@gnu.org
newly installed ubuntu 11.10, could be a compiler/library problem, but configure didn't bork so it's certainly some kind of problem.
out/bin/lilypond --verbose ../input/regression/tablature-negative-fret.ly
suppressed warning: Requested string for pitch requires negative fret: string 1 pitch #<Pitch c' >
suppressed warning: Ignoring string request and recalculating.
Segmentation fault
(full output attached)
marking it critical since that regtest is deliberately supposed to handle this case (AFAIK). otherwise it'd be type-crash.
Discussion
Originally posted by: dak@gnu.org
Can you run this under gdb? A backtrace would likely be helpful. Such as
gdb out/bin/lilypond
run input/regression/tablature-negative-fret.ly
backtrace
Originally posted by: Carl.D.S...@gmail.com
Does it segfault if you compile without optimization?
Originally posted by: percival.music.ca@gmail.com
right, sorry, no clue why I didn't do a backtrace immediately.
@Carl: no segfault when compiling without optimization.
bt:
#0 Grob::internal_set_property (this=0x1a, sym=0xb607cb90, v=0x1a)
at /home/gperciva/src/lilypond/lily/grob-property.cc:112
#1 0x082c0c0b in Engraver_dispatch_list::apply (this=0x85d08e8, gi=...)
at /home/gperciva/src/lilypond/lily/translator-dispatch-list.cc:35
#2 0x080f2179 in acknowledge_grobs (this=0x8504870)
at /home/gperciva/src/lilypond/lily/engraver-group.cc:129
#3 Engraver_group::acknowledge_grobs (this=0x8504870)
at /home/gperciva/src/lilypond/lily/engraver-group.cc:90
#4 0x080f26a8 in Engraver_group::do_announces (this=0x8504870)
at /home/gperciva/src/lilypond/lily/engraver-group.cc:178
#5 0x080f268f in Engraver_group::do_announces (this=0x84c7340)
at /home/gperciva/src/lilypond/lily/engraver-group.cc:169
#6 0x0821f5b1 in one_time_step (this=0x84c7340)
at /home/gperciva/src/lilypond/lily/score-engraver.cc:152
#7 Score_engraver::one_time_step_callback (self=0x84c7340, ev=0xb7aff608)
at /home/gperciva/src/lilypond/lily/score-engraver.cc:145
#8 0x080e251a in Dispatcher::dispatch (this=0x847a550, sev=0xb7aff608)
at /home/gperciva/src/lilypond/lily/dispatcher.cc:152
#9 0x080d70c7 in Context::internal_send_stream_event (this=0x84ddb9c,
type=0xb72d4980, origin=0x0, props=0xbfffc178)
at /home/gperciva/src/lilypond/lily/context.cc:460
#10 0x0811a974 in Global_context::run_iterator_on_me (this=0x84ddb38, iter=
0x84cf0a8) at /home/gperciva/src/lilypond/lily/global-context.cc:16
#11 0x08118e9c in ly_interpret_music_expression (mus=0x84ddb38, ctx=0xb7b424c0)
at /home/gperciva/src/lilypond/lily/global-context-scheme.cc:119
#12 0x08119646 in ly_run_translator (mus=0xb7bc8c68, output_def=0xb7b424c0)
at /home/gperciva/src/lilypond/lily/global-context-scheme.cc:146
#13 0x082245fe in Score::book_rendering (this=0x8482528, layoutbook=0x847a668,
default_def=0x85d5ff0) at /home/gperciva/src/lilypond/lily/score.cc:155
#14 0x080a56e4 in Book::process_score (this=0x847a640, s=0xb7b66f08,
output_paper_book=0x85984b8, layout=0x85d5ff0)
at /home/gperciva/src/lilypond/lily/book.cc:236
#15 0x080a590c in Book::process (this=0x847a640, default_paper=0x85c3b88,
default_layout=0x85d5ff0, parent_part=0x0)
at /home/gperciva/src/lilypond/lily/book.cc:302
#16 0x080a5b27 in Book::process (this=0x847a640, default_paper=0x85c3b88,
default_layout=0x85d5ff0) at /home/gperciva/src/lilypond/lily/book.cc:207
#17 0x080a2b6b in ly_book_process (book_smob=0xb7baa158,
default_paper=0xb76f0718, default_layout=0xb781de80, output=0x1a)
at /home/gperciva/src/lilypond/lily/book-scheme.cc:76
#18 0x0018244b in scm_gsubr_apply () from /usr/lib/libguile.so.17
#19 0x00168294 in scm_dapply () from /usr/lib/libguile.so.17
#20 0x001699c1 in ?? () from /usr/lib/libguile.so.17
#21 0x001702fb in scm_primitive_eval () from /usr/lib/libguile.so.17
#22 0x081e308a in ly_parse_scm (
s=0x848ce18 "(let ((book-handler (if (defined? 'default-toplevel-book-handle
n=0xbfffc758, i=..., safe=false, parser=0x84be200)
at /home/gperciva/src/lilypond/lily/parse-scm.cc:138
#23 0x082e999f in Lily_lexer::yylex (this=0x8479368)
at /home/gperciva/src/lilypond/lily/lexer.ll:358
#24 0x082ee4a6 in yylex (v=0x84be200, loc=0xbfffda00, s=0xbfffddc8)
at /home/gperciva/src/lilypond/lily/parser.yy:3050
#25 yyparse (my_lily_parser=0x84be200) at out/parser.cc:2684
#26 0x08156e63 in Lily_parser::parse_file (this=0x84be200, init=Cannot access memory at address 0x1a
)
at /home/gperciva/src/lilypond/lily/lily-parser.cc:120
#27 0x081544b5 in ly_parse_file (name=0xbfffe094)
at /home/gperciva/src/lilypond/lily/lily-parser-scheme.cc:121
#28 0x001697c1 in ?? () from /usr/lib/libguile.so.17
#29 0x00168334 in scm_dapply () from /usr/lib/libguile.so.17
#30 0x0016e768 in scm_apply () from /usr/lib/libguile.so.17
#31 0x0017003b in scm_call_0 () from /usr/lib/libguile.so.17
#32 0x001ce0ee in scm_body_thunk () from /usr/lib/libguile.so.17
#33 0x001ce373 in scm_c_catch () from /usr/lib/libguile.so.17
#34 0x001ce5b2 in scm_catch_with_pre_unwind_handler ()
from /usr/lib/libguile.so.17
#35 0x0018244b in scm_gsubr_apply () from /usr/lib/libguile.so.17
#36 0x00168294 in scm_dapply () from /usr/lib/libguile.so.17
#37 0x001699c1 in ?? () from /usr/lib/libguile.so.17
#38 0x0016907c in ?? () from /usr/lib/libguile.so.17
#39 0x00168334 in scm_dapply () from /usr/lib/libguile.so.17
#40 0x0016e768 in scm_apply () from /usr/lib/libguile.so.17
#41 0x00170000 in scm_call_1 () from /usr/lib/libguile.so.17
#42 0x008ccd9c in scm_srfi1_for_each ()
from /usr/lib/libguile-srfi-srfi-1-v-3.so
#43 0x00169b57 in ?? () from /usr/lib/libguile.so.17
#44 0x0016907c in ?? () from /usr/lib/libguile.so.17
#45 0x00169771 in ?? () from /usr/lib/libguile.so.17
#46 0x00168334 in scm_dapply () from /usr/lib/libguile.so.17
#47 0x0016e768 in scm_apply () from /usr/lib/libguile.so.17
#48 0x00170000 in scm_call_1 () from /usr/lib/libguile.so.17
#49 0x0816908e in main_with_guile ()
at /home/gperciva/src/lilypond/lily/main.cc:443
#50 0x00186c74 in ?? () from /usr/lib/libguile.so.17
#51 0x00158280 in ?? () from /usr/lib/libguile.so.17
#52 0x001ce373 in scm_c_catch () from /usr/lib/libguile.so.17
#53 0x0015891b in scm_i_with_continuation_barrier ()
from /usr/lib/libguile.so.17
#54 0x00158a05 in scm_c_with_continuation_barrier ()
from /usr/lib/libguile.so.17
#55 0x001cc1bd in scm_i_with_guile_and_parent () from /usr/lib/libguile.so.17
#56 0x001cc2ad in scm_with_guile () from /usr/lib/libguile.so.17
#57 0x00186d75 in scm_boot_guile () from /usr/lib/libguile.so.17
#58 0x0805350a in main (argc=5, argv=0xb607cb80, envp=0xf2c502c6)
at /home/gperciva/src/lilypond/lily/main.cc:645
ick, do you need guile dbg libraries? I don't want to compile that from source. :(
Originally posted by: fedel...@gmail.com
I confirm the segfault (I'm on Debian wheezy).
After running 'configure --disable-optimising && make' it compiles fine.
Find attached the valgrind output.
HTH
Originally posted by: gra...@percival-music.ca
../configure CXXFLAGS="-fno-crossjumping -fkeep-inline-functions"
compiles it with no problems on the command-line. valgrind shows tons of uninitialized variables, but I'm not running it with the suppression file because I haven't gotten around to reading Reinhold's email from a few weeks ago about it.
attached is the valgrind output just in case it helps anyway.
Originally posted by: dak@gnu.org
lilypond@googlecode.com writes:
I have just brainlessly started looking at instances of unsmob* to see
where we might deal with unprotected pointers.
I find it somewhat disconcerting that stuff like struct
Side_position_interface keeps pointers to parent grobs, but is not
smobbified itself.
Does anybody have an idea what keeps parent grobs here alive and safe
from being garbage-collected until Side_position_interface does no
longer need them?
Originally posted by: dak@gnu.org
lilypond@googlecode.com writes:
If the above gets you into a state where Patchy/releases can roll again
from your private computer, I'm willing to spend some time trying to get
the flower link error out of make check.
Deal?
Originally posted by: gra...@percival-music.ca
make doc just finished, and a 30-second poke around the regtests only showed broken regtest. (I have absolutely no reason to suspect the configure options are the cause, so I'm treating it separately)
30 seconds to find a broken regtests is pretty typical for the state of lilypond development over the past 6 months, so I think I can get Patchy going again. Although probably tomorrow morning because I need to get real work done.
I honestly have no recollection of the flower link error, so I can't comment on that.
Originally posted by: dak@gnu.org
lilypond@googlecode.com writes:
make check bombs out with those options _after_ having generated
out/test-results/index.html, while doing make check in the flower
subdirectory.
I'll have another round of trying to figure out the reason, in case this
makes Patchy uncomfortable.
Originally posted by: dak@gnu.org
For progress (or rather nonprogress) of the "make check" sideissue not really belonging in here, check Issue 1875.
Originally posted by: Carl.D.S...@gmail.com
This is probably the same issue as issue 1900, but I'm not going to merge them.
I wonder if we've got the problem that Mike Solomon identified with the use of non-documented properties....
Originally posted by: Carl.D.S...@gmail.com
Could someone who has observed this segfault try again after testing the patch at
http://codereview.appspot.com/5432081/
This is a scheme-only patch, so it should apply very easily. I'd love to know if it fixes the segfault. I've never observed the segfault, so I can't test it.
Thanks,
Carl
Originally posted by: Carl.D.S...@gmail.com
David Kastrup tested the patch, and found that it had no effect on the segfault.
Thanks,
Carl
Originally posted by: dak@gnu.org
Anyway, I have boiled this down to a minimal example that still crashes.
{
\set TabStaff.handleNegativeFrets = #'include
s
}
The problem is apparently setting a property on a not-yet-existing context. Don't ask me what the connection to the compilation options might be: I am off to a party now and won't be able to look at this until tomorrow, I guess.
Originally posted by: dak@gnu.org
Bad news.
void
Tab_staff_symbol_engraver::acknowledge_staff_symbol (Grob_info gi)
{
int k = scm_ilength (get_property ("stringTunings"));
if (k >= 0)
gi.grob ()->set_property ("line-count", scm_from_int (k));
}
#ifndef NDEBUG
/*
TODO: include modification callback support here, perhaps
through intermediate Grob::instrumented_set_property( .. __LINE__ ).
*/
#define set_property(x, y) instrumented_set_property (ly_symbol2scm (x), y, __FILE__, __LINE__, __FUNCTION__)
#else
#define set_property(x, y) internal_set_property (ly_symbol2scm (x), y)
#endif
#define ly_symbol2scm(x) \
({ \
static SCM cached; \
/* We store this one locally, since G++ -O2 fucks up else */ \
SCM value = cached; \
if (__builtin_constant_p ((x))) \
{ \
if (!cached) \
value = cached = scm_gc_protect_object (scm_or_str2symbol (x)); \
} \
else \
value = scm_or_str2symbol (x); \
value; \
})
void
Grob::internal_set_property (SCM sym, SCM v)
{
internal_set_value_on_alist (&mutable_property_alist_,
sym, v);
}
(gdb) disass
Dump of assembler code for function Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info):
0x082b0a60 <+0>: push %ebx
0x082b0a61 <+1>: sub $0x18,%esp
0x082b0a64 <+4>: mov 0x83f3f40,%eax
0x082b0a69 <+9>: mov 0x20(%esp),%ebx
0x082b0a6d <+13>: test %eax,%eax
0x082b0a6f <+15>: je 0x82b0ac0 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+96>
0x082b0a71 <+17>: mov %eax,0x4(%esp)
0x082b0a75 <+21>: mov %ebx,(%esp)
0x082b0a78 <+24>: call 0x82d5050 <Translator::internal_get_property(scm_unused_struct*) const>
0x082b0a7d <+29>: mov %eax,(%esp)
0x082b0a80 <+32>: call 0x804e650 <scm_ilength@plt>
0x082b0a85 <+37>: test %eax,%eax
0x082b0a87 <+39>: js 0x82b0ab8 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+88>
0x082b0a89 <+41>: mov %eax,(%esp)
0x082b0a8c <+44>: call 0x804e2d0 <scm_from_int32@plt>
0x082b0a91 <+49>: mov %eax,%ebx
0x082b0a93 <+51>: mov 0x83f3f44,%eax
0x082b0a98 <+56>: test %eax,%eax
0x082b0a9a <+58>: je 0x82b0ae0 <Tab_staff_symbol_engraver::acknowledge_staff_symbol(Grob_info)+128>
0x082b0a9c <+60>: mov %ebx,0x28(%esp)
0x082b0aa0 <+64>: mov %ebx,0x20(%esp)
0x082b0aa4 <+68>: mov %eax,0x24(%esp)
0x082b0aa8 <+72>: add $0x18,%esp
=> 0x082b0aab <+75>: pop %ebx
0x082b0aac <+76>: jmp 0x812e760 <Grob::internal_set_property(scm_unused_struct*, scm_unused_struct*)>
Function arguments to internal_set_property (starting with this) are
at 0x20(%esp) and following.
So the first argument (after `this') is the memoized string
"line-count". So far, so good. The second argument is the converted
value of k. So far, so nice. However, `this' (the self-pointer) is
_also_ set to value of k rather than the actual grob.
WTF?!?
Apparently GCC-4.6.0 gets confused about what it keeps in which
register.
Does anybody have a reasonable idea how we should be dealing with
compiler problems?
Originally posted by: dak@gnu.org
Ok, this is a steaming heap of crap. I have tried boiling the original preprocessed source down to something more useful, and I have a 25k file not depending on any non-system files that still shows the problem. I sent that to the gcc bug list, but don't expect all too much.
Shall I shove in some garbage code into the affected function so that GCC does not "optimize" it to death by segfault?
Originally posted by: dak@gnu.org
Entered as <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323>.
I'll add appropriate garbage to the function that will keep g++ from making this particular "optimization". Hopefully we don't have more instances of it in our code base.
Originally posted by: dak@gnu.org
Ok, forget it. The next segfault is in input/regression/grid-lines.ly.
I think we can't do much more than recommend
./autogen.sh CXXFLAGS=-fkeep-inline-functions
for g++-4.6.1. I don't have the energy to figure out all the places where the code generation fails and add totally ugly workarounds.
This is really too time-intensive.
Originally posted by: dak@gnu.org
At least the following are likely to be broken (since they are quite similar and I get already 2 of them bad).
lily/font-size-engraver.cc: gi.grob ()->set_property ("font-size", scm_from_dou
lily/ligature-engraver.cc: info.grob ()->set_property ("stencil", brew_li
lily/new-fingering-engraver.cc: inf.grob ()->set_property ("style", ly_
lily/pitch-squash-engraver.cc: i.grob ()->set_property ("staff-position", new
lily/tab-staff-symbol-engraver.cc: gi.grob ()->set_property ("line-count", sc
lily/tweak-engraver.cc: info.grob ()->set_property (scm_caar (s), scm_c
And then I get something like
Preprocessing graphical objects.../usr/local/tmp/lilypond/out/share/lilypond/current/scm/output-lib.scm:139:9: In procedure ly:event-property in expression (ly:event-property (event-cause grob) (quote duration)):
/usr/local/tmp/lilypond/out/share/lilypond/current/scm/output-lib.scm:139:9: Wrong type argument in position 1 (expecting Stream_event): #f
g++-4.6.1 is a bottomless pit, period. I don't see that anything but workaround options makes sense here.
Originally posted by: Carl.D.S...@gmail.com
Can we test for g++-4.6.1, and add the CXXFLAGS=-fkeep-inlinefunctions automatically as part of configure.sh?
Thanks for tracking this down, David! I certainly couldn't have done it, and I can see that it's lots of work. I really appreciate your doing this.
Carl
Originally posted by: gra...@percival-music.ca
hmm, fun and joy here. Brand new mac mini, brand new installation of ubuntu 11.10. make, make doc, make test-baseline, make check is happy. So is your crash from comment 14.
gperciva@chikara:~/src/lilypond$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
gperciva@chikara:~/src/lilypond$ git show
commit [r45b219221124f4d7b977a1a0b1e489c47bb3ac02]
...
gperciva@chikara:~/src/lilypond/build$ uname -a
Linux chikara 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
gperciva@chikara:~/src/lilypond/build$ out/bin/lilypond crash-comment-14.ly
GNU LilyPond 2.15.21
Processing `crash-comment-14.ly'
Parsing...
crash-comment-14.ly:0: warning: no \version statement found, please add
\version "2.15.21"
for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `crash-comment-14.ps'...
Converting to `./crash-comment-14.pdf'...
Success: compilation successfully completed
Where to go next? Well, I suppose it _could_ be due to uninitialized variables. As previously discussed, I'm starting a vendetta against those. The machine code is a bit beyond me, I'm afraid.
Originally posted by: dak@gnu.org
Graham, you have a 64bit target. The code generator for that is entirely different from 32bit systems. It may suffer from a similar problem exposed under different circumstances (which might or might not be triggered in the Lilypond code base, although at least the regtest does not see them), or it may not be affected at all. This segfault is not due to uninitialized variables, it is a compiler fault. You can trust me on that. I have a couple dozen years of system programming experience.
Anyway, one thing that has been useful is figuring out "target record" in gdb which lets you step backwards from a segfault. Since various other optimizations made the stack backtrace less than useful (since the problem occurs with tail jump optimizations, the bad function is not actually present in the backtrace), this was quite helpful.
I will try seeing whether we can use a more specific option than the keep-inline-function stuff. Unfortunately, I have not been able to isolate a nice self-contained test case that we could employ as a more reliable configure test than just testing for a gcc version number.
Do we have any data from 4.6.0? I know that 4.6.1 is faulty (no idea whether just i386 target is affected, but at least ia64 seems less troubled), but nothing else. Strictly speaking, we don't even know whether it is just Ubuntu's own version.
Short of more conclusive data, I'd do a configure check for >= 4.6.0 and rein that in when we get more conclusive data.
Cc: gra...@percival-music.ca
Status: Started
Originally posted by: dak@gnu.org
The right option for avoiding the bad optimization would appear to be -fno-optimize-sibling-calls and, frankly, it is actually insane that -fkeep-inline-functions works as well since it is documented as doing something completely unrelated to the faulty code generation.
Switching off sibling call optimization will also improve the usefulness of stack backtraces for debugging and diagnosis since it does not clobber the stack frames of callers that have nothing left to do except return.
I doubt that the we'll even notice the added stack usage since we don't really employ the sort of call chaining in C++ where this optimization renders noticeable savings.
Originally posted by: dak@gnu.org
Work around compiler bug, Issue 1997: segfault in tablature-negative-fret.ly
http://codereview.appspot.com/5431088
Labels: Patch-new
Originally posted by: dak@gnu.org
If you look at the GCC bug URL given in comment 17, you'll see that Jakub Jelinek has given a self-contained example that is supposed to correlate with the bug.
This example is written in pure C. Since I don't really have the expertise to judge whether it really is the same bug, after some thought I'd feel more comfortable staying with a version-based check for now.
If you take a look at the gcc patch that Jakub claims fixes the problem, you'll see that it is in gcc/calls.cc and it does appear to be in an architecture _independent_ part of the source. That Graham's version of gcc on x86_64 did not fail in the same manner for this reason would not seem to imply that it won't fail under different circumstances related to structure arguments.
Since this is rather ugly to diagnose and the backtraces basically are useless for that purpose as well, I would tend to make my patch specify the workaround option _independent_ of the architecture, to be on the safe side. Because _if_ any x86_64 bugs do appear, I don't have the hardware to diagnose them, and they will look different from the bugs we had on i686.
Sounds reasonable?
If so, I'll take the architecture check out of my patch.