Re: no solution found for Bezier intersection

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2018-07-01 23:07 GMT+02:00 David Kastrup <address@hidden>:
>> Thomas Morley <address@hidden> writes:
>>
>>> 2018-07-01 21:13 GMT+02:00 David Kastrup <address@hidden>:
>>>
>>>> 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.
>>
>> address@hidden:/usr/local/tmp/lilypond$ cd /tmp
>> address@hidden:/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 (address@hidden, address@hidden,
>> address@hidden) 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