Thomas Morley <[email protected]> writes: > 2018-07-01 23:07 GMT+02:00 David Kastrup <[email protected]>: >> Thomas Morley <[email protected]> writes: >> >>> 2018-07-01 21:13 GMT+02:00 David Kastrup <[email protected]>: >>> >>>> Perhaps try running under a debugger and setting a breakpoint on >>>> ::warning (or so)? Then make a traceback when the warning is reached >>>> (hopefully from the right point). >>> >>> Well, I don't know what I should do. I never did something like this. >>> >>> But I tried: >>> >>> gdb lilypond/usr/bin/lilypond >>> [...] >>> (gdb) break ::error >>> Breakpoint 1 at 0x7ffff5b20390: file error.c, line 294. >>> (gdb) run file-bug.ly >>> [...] >>> (gdb) bt >>> No stack. >>> >>> >>> Probably I did it not correctly.
Well, close enough for the incorrect instructions I gave. I focused on "warning" when the actual diagnostic was a "programming error". >> It's programming_error actually. >> >> dak@lola:/usr/local/tmp/lilypond$ cd /tmp >> dak@lola:/tmp$ gdb /usr/local/tmp/lilypond/out/bin/lilypond >> GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git >> Copyright (C) 2018 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>. >> Find the GDB manual and other documentation resources online at: >> <http://www.gnu.org/software/gdb/documentation/>. >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /usr/local/tmp/lilypond/out/bin/lilypond...done. >> (gdb) break programming_error >> Breakpoint 1 at 0xc9880: programming_error. (3 locations) >> (gdb) run /tmp/harm.ly >> Starting program: /usr/local/tmp/lilypond/out/bin/lilypond /tmp/harm.ly >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> GNU LilyPond 2.21.0 >> Processing `/tmp/harm.ly' >> Parsing... >> Interpreting music...[8][16] >> Preprocessing graphical objects... >> Finding the ideal number of pages... >> Fitting music on 1 page... >> Drawing systems... >> Breakpoint 1, programming_error (s="no solution found for Bezier >> intersection", location="") at warn.cc:190 >> 190 { >> (gdb) bt >> #0 0x0000555555923ed0 in >> programming_error(std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > const&, >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> > const&) (s="no solution found for Bezier >> intersection", location="") at warn.cc:190 >> #1 0x0000555555757968 in Bezier::get_other_coordinate(Axis, double) >> const (this=this@entry=0x5555562fb628, a=a@entry=X_AXIS, >> x=x@entry=90.173852841682958) at bezier.cc:72 >> #2 0x00005555557c576c in >> Slur_configuration::score_extra_encompass(Slur_score_state const&) >> (this=0x5555562fb5e0, state=...) at slur-configuration.cc:411 >> #3 0x00005555557c6085 in >> Slur_configuration::run_next_scorer(Slur_score_state const&) >> (this=0x5555562fb5e0, state=...) at slur-configuration.cc:522 > > Good luck... > > Thanks for posting the entire commands and their returnings. > I've studied what you did, probably (likely?) I can do it myself next time. Well yes, sorry for not giving good enough instructions first time round. I had to compile a new LilyPond as my current binary was out of sync with the Scheme code and would not run (jumped around between too many branches). -- David Kastrup _______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
