Hi Michael, Am Montag, dem 15.03.2021 um 12:03 +0100 schrieb 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'm confused here: Was the initial segmentation fault also on master or with MR !683 applied? > 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 This is in the branch of "if (ly_is_procedure (creation_callback))", which probably means two things: 1. It might be related to the changes in MR !683 because my understanding is that Graphiz is the only user of ly:set-grob-creation- callback. 2. Depending on whether you hit the fault when processing input/regression/graphviz.ly (my understanding is you don't?), the creation callback is not reset after a session (= an input file) ends. Jonas
signature.asc
Description: This is a digitally signed message part