Re: Mysterious crash in BDWGC on Windows

[Jean Abou Samra <jean@abou-samra.fr>]

Reposting because of mangled formatting, sorry. Not sure what went wrong.

Hi Guilers,

Sorry about the double post on guile-devel and guile-user,
I wasn't sure which one was more appropriate for this.

In LilyPond, we're getting random crashes on Windows builds,
with Guile 2.2 [*]. These are builds are done by cross-compilation
to MinGW. Tracker issue:

https://gitlab.com/lilypond/lilypond/-/issues/6361


Example backtrace (trimmed):

Thread 1 received signal SIGSEGV, Segmentation fault.
GC_mark_from (mark_stack_top=0x24956eb0ae0, mark_stack=0x24956eb0000, 
mark_stack_limit=0x24956ec0000) at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/mark.c:816
816 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/mark.c: 
No such file or directory.
(gdb) backtrace
#0 GC_mark_from (mark_stack_top=0x24956eb0ae0, mark_stack=0x24956eb0000, 
mark_stack_limit=0x24956ec0000)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/mark.c:816
#1 0x00007ff6c2950338 in GC_mark_some (cold_gc_frame=0x7b439fba10 "\006")
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/mark.c:321
#2 0x00007ff6c2947a25 in GC_stopped_mark 
(stop_func=stop_func@entry=0x7ff6c29478b0 <GC_never_stop_func>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/alloc.c:880
#3 0x00007ff6c2948abb in GC_try_to_collect_inner 
(stop_func=stop_func@entry=0x7ff6c29478b0 <GC_never_stop_func>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/alloc.c:626
#4 0x00007ff6c2948d58 in GC_try_to_collect_inner 
(stop_func=0x7ff6c29478b0 <GC_never_stop_func>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/alloc.c:577
#5 GC_try_to_collect_general (stop_func=stop_func@entry=0x0, 
force_unmap=force_unmap@entry=0)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/alloc.c:1298
#6 0x00007ff6c294918d in GC_gcollect ()
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/gc-8.2.0/alloc.c:1323
#7 0x00007ff6c2896b69 in scm_i_gc (what=<synthetic pointer>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/guile-2.2.7/libguile/gc.c:266
#8 scm_gc () at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/guile-2.2.7/libguile/gc.c:255
#9 0x00007ff6c290788f in vm_regular_engine (thread=0x0, 
vp=0x2495b083f30, registers=0x24956ec0000, resume=1016)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/guile-2.2.7/libguile/vm-engine.c:786
#10 0x00007ff6c2909c9b in scm_call_n (proc=0x249590a3d40, 
argv=argv@entry=0x7b439fbe78, nargs=nargs@entry=1)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/guile-2.2.7/libguile/vm.c:1260
#11 0x00007ff6c288ee19 in scm_call_1 (proc=<optimized out>, 
arg1=<optimized out>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/guile-2.2.7/libguile/eval.c:485
#12 0x00007ff6c2836e0a in Method_instance::operator() (this=<optimized out>)
at 
/home/jean/repos/lilypond/release/binaries/mingw/lilypond/lilypond-2.23.10/lily/include/callback.hh:212
#13 Translator_group::precomputed_translator_foreach 
(idx=STOP_TRANSLATION_TIMESTEP, this=0x2495d75bb90)
at 
/home/jean/repos/lilypond/release/binaries/mingw/lilypond/lilypond-2.23.10/lily/translator-group.cc:267



As a further data point, the bug only reproduces with address space
layout randomization enabled.


Do you have any idea what might be causing this? At LilyPond, we're
totally lost on what could provoke such an internal crash in BDWGC.
Do you have successful experience with using Guile 2.2 on Windows?
Did you see this kind of thing before? In short, does it ring a bell?

Thanks,
Jean

[*] I quickly tried checking if they reproduced with Guile 3 but got a
     boot failure and didn't dig deeper. See the issue.