Thomas Morley <thomasmorle...@gmail.com> 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
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
