Segmentation fault during `make check'

[Michael Käppler]

Hi all,
I encountered a segmentation fault that happens sporadically during a
'make check' run.
See https://gitlab.com/lilypond/lilypond/-/merge_requests/683 for some
context.

It is not reproducable with a specific snippet, but I could reproduce it
on top of a failed
'make check' run by running the 'lilypond' command that failed.

Unfortunately, it seems somehow related to optimization, because the
identical setup
with an unoptimized lilypond binary (compiled in a different tree from
same 'master') does
not fail. Pretty hard to track it down...

I do not know if the stack trace of the optimized binary is useful, but:

#0  0x00007ffff780aa1c in scm_dapply (proc=0x404, arg1=<optimized out>,
args=0x7fffec751010)
    at eval.c:4989
#1  0x0000555555669b84 in
Engraver::internal_make_grob(scm_unused_struct*, scm_unused_struct*,
char const*, int, char const*) (this=<optimized out>,
symbol=0x7ffff2fc4920, cause=cause@entry=0x404, file=0x5555558d2848
"/home/michael/lilypond/lily/paper-column-engraver.cc", line=73,
fun=0x5555558d2f28 <Paper_column_engraver::make_columns()::__FUNCTION__>
"make_columns") at /home/michael/lilypond/lily/engraver.cc:146
#2  0x0000555555669ea7 in
Engraver::internal_make_column(scm_unused_struct*, char const*, int,
char const*) (this=<optimized out>, x=<optimized out>, file=<optimized
out>, line=<optimized out>, fun=<optimized out>) at
/home/michael/lilypond/lily/engraver.cc:166
#3  0x0000555555758b9e in Paper_column_engraver::make_columns()
(this=this@entry=0x5555561a59b0)
    at /home/michael/lilypond/lily/paper-column-engraver.cc:73
#4  0x0000555555758e3d in Paper_column_engraver::initialize()
(this=0x5555561a59b0)
    at /home/michael/lilypond/lily/paper-column-engraver.cc:82
#5  0x000055555584c317 in Callbacks::trampoline<Translator,
&Translator::initialize>(scm_unused_struct*) (target=<optimized out>) at
/home/michael/lilypond/lily/include/callback.hh:114
#6  0x00007ffff780ad86 in scm_dapply (proc=0x7ffff0f7a220,
arg1=0x7fffec7ad290, args=0x404) at eval.c:5019
#7  0x000055555584b5b1 in translator_each(scm_unused_struct*,
scm_unused_struct*) (method=<optimized out>, list=<optimized out>) at
/home/michael/lilypond/lily/translator-group.cc:45
#8  0x000055555584b5b1 in recurse_over_translators(Context*,
scm_unused_struct*, scm_unused_struct*, Direction)
(c=c@entry=0x555556573340, ptr=0x7ffff0f7a220,
tg_ptr=tg_ptr@entry=0x7ffff0f7a240, dir=dir@entry=DOWN) at
/home/michael/lilypond/lily/translator-group.cc:211
#9  0x000055555584b9d2 in
Translator_group::create_child_translator(scm_unused_struct*)
(this=<optimized out>, sev=<optimized out>) at
/home/michael/lilypond/lily/translator-group.cc:169
#10 0x000055555584c3b5 in Callbacks::trampoline<Translator_group,
&Translator_group::create_child_translator>(scm_unused_struct*,
scm_unused_struct*) (target=<optimized out>, ev=<optimized out>)
    at /home/michael/lilypond/lily/include/callback.hh:124
#11 0x00007ffff780afaf in scm_dapply (proc=0x7ffff0f804a0,
arg1=0x7fffece1cfc0, args=0x7fffec7adbf0)
    at eval.c:5021
#12 0x0000555555652627 in Listener::listen(scm_unused_struct*)
(ev=<optimized out>, this=<optimized out>)
    at /home/michael/lilypond/lily/include/listener.hh:108
#13 0x0000555555652627 in
Smob_base<Listener>::smob_trampoline<&Listener::listen>(scm_unused_struct*,
scm_unused_struct*) (self=<optimized out>, arg1=<optimized out>)

Maybe related to garbage collection?
Does anyone have a clue?

Michael