crash running translator

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

crash running translator

Jan-Peter Voigt
Dear all,

I stumbled over something that looks like a bug.
If one uses ly:run-translator to process some music a dotted rest
crashes lilypond:

\version "2.19.82"
#(ly:run-translator #{ r2. #} #{ \layout {} #})

The error message is:
Wrong number of arguments to #<procedure lookup-font (node alist-chain)>

Does anybody know a way to circumvent this?

Jan-Peter

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: crash running translator

David Kastrup
Jan-Peter Voigt <[hidden email]> writes:

> Dear all,
>
> I stumbled over something that looks like a bug.
> If one uses ly:run-translator to process some music a dotted rest
> crashes lilypond:
>
> \version "2.19.82"
> #(ly:run-translator #{ r2. #} #{ \layout {} #})
>
> The error message is:
> Wrong number of arguments to #<procedure lookup-font (node alist-chain)>
>
> Does anybody know a way to circumvent this?

Well, looking up the definition of ly:run-translator I read:

LY_DEFINE (ly_run_translator, "ly:run-translator",
           2, 1, 0, (SCM mus, SCM output_def),
           "Process @var{mus} according to @var{output-def}.  An"
           " interpretation context is set up, and @var{mus} is"
           " interpreted with it.  The context is returned in its"
           " final state.\n"
           "\n"
           "Optionally, this routine takes an object-key to"
           " to uniquely identify the score block containing it.")
[...]

Which makes me barf.  The final paragraph is just gobbledygook.  It
doesn't help that this mysterious optional object-key is _accepted_ but
the function signature does not even contain a parameter declaration for
it.

Ok, onward.  Running with -dverbose I get

-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Mon Sep 17 15:45:07

lilypond -dverbose gok.ly
GNU LilyPond 2.21.0
]
]
]
]
]
[... we should probably do something about those, dozens more]
Processing `gok.ly'
Parsing...
Interpreting music...Backtrace:
In unknown file:
   ?:  0* [lilypond-main ("gok.ly")]
In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
1032:  1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
1032:  2* [lilypond-all ("gok.ly")]
1045:  3  (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...)
1057:  4* [for-each #<procedure #f (x)> ("gok.ly")]
In unknown file:
   ?:  5* [#<procedure #f (x)> "gok.ly"]
In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
1059:  6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
1070:  7* [lilypond-file #<procedure #f (key failed-file)> "gok.ly"]
1105:  8  [catch ly-file-failed #<procedure #f ()> #<procedure #f (x . args)>]
In unknown file:
   ?:  9* [#<procedure #f ()>]
In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
1106: 10* [ly:parse-file "gok.ly"]
In gok.ly:
   Now it's getting interesting:

   2: 11* [ly:run-translator # #]
In unknown file:
   ?: 12* [# #]
   ?: 13* [# # #]
   ?: 14* [#<Callback2_wrapper> #<Translator Dot_column_engraver > #<Grob Rest > ...]
   ?: 15* [ly:rest::width #<Grob Rest >]
   ?: 16* [lookup-font #<undefined> ((# # # #) (# # # # ...) ())]

ERROR: In procedure lookup-font:
ERROR: Wrong number of arguments to #<procedure lookup-font (node alist-chain)>

Compilation exited abnormally with code 1 at Mon Sep 17 15:45:08

Ok, so we have
SCM
Rest::width (SCM smob)
{
  return generic_extent_callback (unsmob<Grob> (smob), X_AXIS);
}

and

Rest::generic_extent_callback (Grob *me, Axis a)
{
  /*
    Don't want ledgers: ledgers depend on Y position, which depends on
    rest collision, which depends on stem size which depends on beam
    slop of opposite note column.

    consequence: we get too small extents and potential collisions
    with ledgered rests.
  */
  SCM m = brew_internal_stencil (me, a != X_AXIS);
  return ly_interval2scm (unsmob<Stencil> (m)->extent (a));
}

and

Rest::brew_internal_stencil (Grob *me, bool ledgered)
{
  SCM durlog_scm = me->get_property ("duration-log");
  if (!scm_is_number (durlog_scm))
    return Stencil ().smobbed_copy ();

  int durlog = scm_to_int (durlog_scm);

  string style = robust_symbol2string (me->get_property ("style"), "default");

  Font_metric *fm = Font_interface::get_default_font (me);
  string font_char = glyph_name (me, durlog, style, ledgered, 0.0);
  Stencil out = fm->find_by_name (font_char);
  if (out.is_empty ())
    me->warning (_f ("rest `%s' not found", font_char.c_str ()));

  return out.smobbed_copy ();
}


Actually, looking at the traceback it would seem like lookup-font is not
actually called with the wrong number of arguments but something is
confused by the first argument being *undefined*.  Which is a value that
usually is used in the C API for signifying "there isn't a proper Scheme
value here", so passing it around can lead to surprises.

This appears to be the problem from

Font_metric *
Font_interface::get_default_font (Grob *me)
{
  Font_metric *fm = unsmob<Font_metric> (me->get_property ("font"));
  if (!fm)
    {
      SCM chain = music_font_alist_chain (me);

      fm = select_font (me->layout (), chain);
      me->set_property ("font", fm->self_scm ());
    }

  return fm;
}

And likely because of me->layout () being unsuitable.  Or not.

The problem only occurs with dotted rests.  Maybe the dots rely on work
being done already by the rest itself but get typeset first?

I don't really know.  This is sort of as deep as I get right now.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user