Re: request: better error message

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Hi all,
>
> I just tried to to update/review and modify an old score. I've got an
> assertion failure.
>
> With released 2.19.65:
> /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/grob-property.cc:242:
> scm_unused_struct* Grob::try_callback_on_alist(scm_unused_struct**,
> SCM, SCM): Assertion `((((scm_t_bits) (0? (*(SCM*)0=((value))):
> (value))) == ((scm_t_bits) (0? (*(SCM*)0=(((SCM) ((((4)) << 8) +
> scm_tc8_flag)))): ((SCM) ((((4)) << 8) + scm_tc8_flag)))))) ||
> (((scm_t_bits) (0? (*(SCM*)0=(value)): value)) == ((scm_t_bits) (0?
> (*(SCM*)0=(marker)): marker)))' failed.
> Aborted (core dumped)
>
> With a build from recent master:
> /home/hermann/lilypond-git/lily/grob-property.cc:242:
> scm_unused_struct* Grob::try_callback_on_alist(scm_unused_struct**,
> SCM, SCM): Assertion `scm_is_null (value) || scm_is_eq (value,
> marker)' failed.

Hey, that error message is an improvement.  The funny thing is that I am
responsible for that improvement (because those error messages were
getting on my nerves), but it is actually a patch to the GNU C library
rather than to LilyPond.  It would appear that you are compiling with a
newer version of the C library than our distributed 2.19.65 is using.

> It took my quite a while and was going on my nerves before I found the
> culprit in my file with a lot of included functions from other files,
> etc, etc. The above error-messages didn't help in any way.
> Could we please put out a meaningful message for the problem triggered
> with (stripped down):
>
> \version "2.19.65"
>
> {
>   \override Fingering #'stencil =
>     #(lambda (grob)
>       (ly:grob-set-property! grob 'stencil
>         (grob-interpret-markup grob #{ \markup \normal-text "foo" #})))
>   a''-1
> }
>
> I doubt many people would have been able to read the error and
> directly point to the faulty coding.

Assertion failures should not be triggered by users anyway.  They point
to a violation of the program's assumptions severe enough that it makes
no sense to continue.  So this should likely become a programming error
instead.

You still won't get sensible behavior here since the return value will
(I think) be wrong, too.

-- 
David Kastrup