Petr Gajdos <pgajdos <at> suse.cz> writes: > I have same symptoms like Phil described.
> Core was generated by `/usr/bin/lilypond -dpreview -dresolution=150 -o ./ out-www orchestra.ly'. If I understand correctly, this gives a way to reproduce the bug, on a 64-bit GNU/Linux system, without building the entire Documentation. Maybe one of us who knows LilyPond but is running a 32-bit system can use the debugger to see what might be wrong with the data structures at the lines indicated by the backtrace. > Program terminated with signal 11, Segmentation fault. > #0 Skyline::Skyline (this=0x7fff25f2f680, src=...) at skyline.cc:468 > 468 buildings_.push_back (Building ((*i))); > #3 Side_position_interface::aligned_side (me=0x13fcb50, a=a <at> entry=Y_AXIS, > pure=pure <at> entry=true, start=start <at> entry=0, end=end <at> entry=24, current_off=0x0) > at side-position-interface.cc:240 Looking at the stack back-trace and the input file, the backtrace matches what should be happening while LilyPond is estimating the position of the tempo mark (Presto 4.=112) relative to its custom "MarkLine" context, which context contains nothing besides that tempo mark. If that is so, an \override MetronomeMark.Y-offset=#0 at line 99 of orchesra.ly should avoid the problem. And then, reversing some of the patch for issue 3199 might fix it. One thing that doesn't fit my theory is Phil's report that changing almost anything in the input file avoids the problem. If changing a few pitches in the input avoids the problem, it might be a floating-point issue along the lines of issue 3383. _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
