Re: Assertion failure on current master
On Oct 1, 2011, at 7:01 PM, m...@apollinemike.com wrote: On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote: Hey guys, I can't complete test-baseline due to an assertion error running mozart-hrn-3.ly. Here's the backtrace: Drawing systems...lilypond: ../flower/include/interval.hh:226: T Interval_tT::center() const [with T = double]: Assertion `!is_empty ()' failed. Program received signal SIGABRT, Aborted. (gdb) bt #0 0x7508fd05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x75093ab6 in abort () at abort.c:92 #2 0x750887c5 in __assert_fail (assertion=0x70bd60 !is_empty (), file=value optimised out, line=226, function=value optimised out) at assert.c:81 #3 0x0041bf01 in Interval_tdouble::center (this=0x7fff7310) at ../flower/include/interval.hh:226 #4 0x006d8b2c in Tuplet_number::calc_y_offset (smob=0x722bebe0) at tuplet-number.cc:83 #5 0x77926ae4 in scm_dapply () from /usr/lib/libguile.so.17 #6 0x004fc65f in Grob::try_callback_on_alist (this=0x108d150, alist=0x108d1b0, sym=0x72a6c080, proc=0x745ac530) at grob-property.cc:231 #7 0x004fc398 in Grob::internal_get_property (this=0x108d150, sym=0x72a6c080) at grob-property.cc:188 #8 0x00505efd in Grob::get_offset (this=0x108d150, a=Y_AXIS) at grob.cc:383 #9 0x00505a67 in Grob::relative_coordinate (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:312 #10 0x005062a4 in Grob::extent (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:427 #11 0x0043a1ad in add_boxes (me=0x108d150, x_common=0x18950a0, Looks like the new tuplet collision avoidance code. Cheers, Neil Hey Neil, I just ran mozart-hrn-3.ly on an unoptimized binary and could not reproduce the problem. Could someone else please verify? A follow-up: I can't figure out how the error could come about. Interval::center should, in Tuplet_number::calc_y_offset, always be getting an interval for which it can find the center (it uses robust_scm2interval). Does anyone with more computer chops than I have have any intuition about this? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:04, m...@apollinemike.com m...@apollinemike.com wrote:
A follow-up: I can't figure out how the error could come about.
Interval::center should, in Tuplet_number::calc_y_offset, always be getting
an interval for which it can find the center (it uses robust_scm2interval).
Does anyone with more computer chops than I have have any intuition about
this?
The interval it fails on is empty here:
(gdb) f 4
#4 0x006d8b2c in Tuplet_number::calc_y_offset
(smob=0x722bebe0) at tuplet-number.cc:83
83return scm_from_double (positions.center ());
(gdb) p positions
$1 = {Drul_arraydouble = {array_ = {4.158845306777426,
3.5388453067774259}}, No data fields}
I'll try to narrow it down by gutting the movement which has the
triplets. They all look pretty benign though.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On Sat, Oct 01, 2011 at 07:04:25PM +0200, m...@apollinemike.com wrote: On Oct 1, 2011, at 7:01 PM, m...@apollinemike.com wrote: On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote: Drawing systems...lilypond: ../flower/include/interval.hh:226: T Interval_tT::center() const [with T = double]: Assertion `!is_empty ()' failed. I just ran mozart-hrn-3.ly on an unoptimized binary and could not reproduce the problem. Could someone else please verify? The problem is verified; I see exactly the same behaviour as Neil with 4f49b000d6e257724e311b406e2346b8388c1f0e Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:16, Graham Percival gra...@percival-music.ca wrote:
The problem is verified; I see exactly the same behaviour as Neil
with 4f49b000d6e257724e311b406e2346b8388c1f0e
Here's a minimal snippet which fails:
\version 2.15.14
\relative c' {
\times 2/3 { f8 e d }
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
Hello, On Sat, Oct 1, 2011 at 6:01 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote: Hey guys, I can't complete test-baseline due to an assertion error running mozart-hrn-3.ly. Here's the backtrace: Drawing systems...lilypond: ../flower/include/interval.hh:226: T Interval_tT::center() const [with T = double]: Assertion `!is_empty ()' failed. Program received signal SIGABRT, Aborted. (gdb) bt #0 0x7508fd05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x75093ab6 in abort () at abort.c:92 #2 0x750887c5 in __assert_fail (assertion=0x70bd60 !is_empty (), file=value optimised out, line=226, function=value optimised out) at assert.c:81 #3 0x0041bf01 in Interval_tdouble::center (this=0x7fff7310) at ../flower/include/interval.hh:226 #4 0x006d8b2c in Tuplet_number::calc_y_offset (smob=0x722bebe0) at tuplet-number.cc:83 #5 0x77926ae4 in scm_dapply () from /usr/lib/libguile.so.17 #6 0x004fc65f in Grob::try_callback_on_alist (this=0x108d150, alist=0x108d1b0, sym=0x72a6c080, proc=0x745ac530) at grob-property.cc:231 #7 0x004fc398 in Grob::internal_get_property (this=0x108d150, sym=0x72a6c080) at grob-property.cc:188 #8 0x00505efd in Grob::get_offset (this=0x108d150, a=Y_AXIS) at grob.cc:383 #9 0x00505a67 in Grob::relative_coordinate (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:312 #10 0x005062a4 in Grob::extent (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:427 #11 0x0043a1ad in add_boxes (me=0x108d150, x_common=0x18950a0, Looks like the new tuplet collision avoidance code. Cheers, Neil Hey Neil, I just ran mozart-hrn-3.ly on an unoptimized binary and could not reproduce the problem. Could someone else please verify? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel I don't get what Neil gets but when I run make -j7 CPU_COUNT=7 test-baseline on a '--disable-optimsed' out of tree build for the latest commit 4f49b000d6e257724e311b406e2346b8388c1f0e I get --snip-- possibilities for bes: (bes besT) possibilities for f: (f fT) possibilities for fis: (fis fisT) possibilities for gis: (gis gisT) possibilities for thumb-bes: (thumb-bes thumb-besT) possibilities for thumb-e: (thumb-e thumb-eT) possibilities for thumb-fis: (thumb-fis thumb-fisT) job 4 terminated with signal: 6 job 3 terminated with signal: 6 etc. --snip-- I can't see where it is failing. The possibilities for bes: (bes besT) possibilities for f: ... I always get when making a test-baseline or check so I know they are nothing to do with this... but it just borks at this point along the make process. Neil what command do you run when you do a test-baseline so that I might get something like you do? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:19, Peekay Ex pkx1...@gmail.com wrote: Neil what command do you run when you do a test-baseline so that I might get something like you do? I don't. :) I couldn't work out which file was failing, so I did what I usually do: run all the regression tests until it crashes. The output I've posted is from debugging mozart-hrn-3.ly on its own via GDB. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote: On 1 October 2011 18:19, Peekay Ex pkx1...@gmail.com wrote: Neil what command do you run when you do a test-baseline so that I might get something like you do? I don't. :) I couldn't work out which file was failing, so I did what I usually do: run all the regression tests until it crashes. The output I've posted is from debugging mozart-hrn-3.ly on its own via GDB. Cheers, Neil Scheiße. I still can't reproduce the problem on my VBox with the unoptimized binary, so all of my suggestions to try to help make this go away will be from thought experiments. It seems as if robust_scm2interval is getting the interval from the property lookup instead of using the default Interval (0.0,0.0), as otherwise this crash wouldn't happen because there would be two valid values. This means that in memory-land, somehow, somewhere, the interval that is accessed for positions is somehow being garbled such that Interval::center can't do its thing. A one-line solution would just be to check in calc_y_offset that the interval actually has values before calling center, but this would be painting over rust (as Reinhold would say). Could someone revert the tuplet patch and see if it compiles clean? Again, sorry I can't be of much help, but I can't reproduce the error :( Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
Neil, On Sat, Oct 1, 2011 at 6:22 PM, Neil Puttock n.putt...@gmail.com wrote: On 1 October 2011 18:19, Peekay Ex pkx1...@gmail.com wrote: Neil what command do you run when you do a test-baseline so that I might get something like you do? I don't. :) I couldn't work out which file was failing, so I did what I usually do: run all the regression tests until it crashes. The output I've posted is from debugging mozart-hrn-3.ly on its own via GDB. Ah ok, well if I get this when I run LP using --disable-optimising on that ly file - not the same but a failure nonetheless -snip- jlowe@jlowe-lilybuntu2:~/lilypond-git$ lilypond --pdf ./input/regression/mozart-hrn-3.ly GNU LilyPond 2.15.14 Processing `./input/regression/mozart-hrn-3.ly' Parsing... Interpreting music... [8][16][24][32][40][48][56][64][72][80][88][96][104][112][120] Preprocessing graphical objects... Interpreting music... Interpreting music... Interpreting music... [8][16][24][32][40][48] Preprocessing graphical objects... Interpreting music... Interpreting music... [8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144] Preprocessing graphical objects... MIDI output to `mozart-hrn-3.midi'... MIDI output to `mozart-hrn-3-1.midi'... MIDI output to `mozart-hrn-3-2.midi'... Finding the ideal number of pages... Fitting music on 3 or 4 pages... Drawing systems...lilypond: /home/jlowe/lilypond-git/flower/include/interval.hh:226: T Interval_tT::center() const [with T = double]: Assertion `!is_empty ()' failed. Aborted jlowe@jlowe-lilybuntu2:~/lilypond-git$ ^C --snip-- -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote: On 1 October 2011 18:19, Peekay Ex pkx1...@gmail.com wrote: Neil what command do you run when you do a test-baseline so that I might get something like you do? I don't. :) I couldn't work out which file was failing, so I did what I usually do: run all the regression tests until it crashes. The output I've posted is from debugging mozart-hrn-3.ly on its own via GDB. Cheers, Neil Could someone replace the last line of Tuplet_number::calc_y_offset with: return scm_from_double (positions.is_empty () ? 0.0 : positions.center ()); And let me know if this gets rid of the problem? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
m...@apollinemike.com m...@apollinemike.com writes: But I just pushed the actual cure. The problem was that positions stores two Y positions - a left and a right. If the left is higher than right, than the interval is read as empty. So, the center needs to be calculated manually. Interval is not really the right thing to use for positions if one wants to use the instance methods of interval (like is_empty), but I use it because it is already used in tuplet-bracket.cc for the print function (in a way that doesn't risk an assertion error). It could also be put in a real drul array, but there is currently no robust_scm2realdrul. This would definitely be a welcome addition to avoid confusion in the code base. This sounds really really icky. The sort of code I hope never to need to deal with. Could you file a suitable Enhancement issue so that redoing this in a less hackish manner does not get forgotten? That way I have a better chance for my hopes becoming true. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
m...@apollinemike.com m...@apollinemike.com writes: On Oct 1, 2011, at 9:29 PM, David Kastrup wrote: This sounds really really icky. The sort of code I hope never to need to deal with. Could you file a suitable Enhancement issue so that redoing this in a less hackish manner does not get forgotten? That way I have a better chance for my hopes becoming true. Actually, I found a robust_scm2drul that does the trick and pushed it to master. So now, no more kludgy code. Sorry for the panic - I have no clue why my unoptimized binary wasn't failing :( We still have a performance regression on Windows, not on Linux bug open, so for whatever reason, we appear to have a divergence in code paths. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
