Re: failing CI builds

[David Kastrup]

Jonas Hahnfeld <hahnjo@hahnjo.de> writes:

> Am Samstag, den 27.06.2020, 18:25 +0200 schrieb Han-Wen Nienhuys:
>> On Fri, Jun 26, 2020 at 11:37 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
>> > https://gitlab.com/lilypond/lilypond/-/merge_requests/201
>> 
>> Curious, this change can't affect lilypond execution. Are the failures
>> localized to certain runners?
>
> No, I can reproduce this locally with current master when running plain
> "make doc" without parallelism. It started after
>
> commit 99ee305b37d5804cd215cd8a222ec8a1eccb8caf
> Author: Han-Wen Nienhuys <hanwenn@gmail.com>
> Date:   Wed Jun 17 23:12:27 2020 +0200
>
>     Write output files atomically
>
> or more precisely after the command to flush PDF output. However, the
> other MR triggered a similar problem before this commit landed in
> master, so I would tend to say that it just triggers an existing
> problem.
>
>
>> > The latter one is mine and I can reproduce this on my own runner, which
>> > means I can get the log files easily and even connect from the host
>> > with gdb and get a bracktrace (see attached files). It's failing
>> > somewhere deep inside libguile.so - any ideas?
>> 
>> Can you install debug symbols for GUILE? It would be interesting to
>> see a more precise stacktrace.
>
> Did this yesterday (before I had to leave), find it attached.
>
> Jonas
>
> #0  0x00007f01c9165428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x00007f01c916702a in __GI_abort () at abort.c:89
> #2  0x00007f01c91a77ea in __libc_message (do_abort=do_abort@entry=2, 
> fmt=fmt@entry=0x7f01c92bf49f "*** %s ***: %s terminated\n") at 
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007f01c924915c in __GI___fortify_fail (msg=<optimized out>, 
> msg@entry=0x7f01c92bf430 "buffer overflow detected") at fortify_fail.c:37
> #4  0x00007f01c9247160 in __GI___chk_fail () at chk_fail.c:28
> #5  0x00007f01c92490a7 in __fdelt_chk (d=d@entry=1025) at fdelt_chk.c:25
> #6  0x00007f01cbb568a3 in fport_input_waiting (port=<optimized out>) at 
> fports.c:500
> #7  0x00007f01cbb56e54 in fport_wait_for_input (port=<optimized out>) at 
> fports.c:567
> #8  fport_fill_input (port=<optimized out>) at fports.c:599
> #9  0x00007f01cbb7877c in scm_getc (port=0x7f01b13c8f60) at 
> ../libguile/inline.h:329
> #10 scm_read_char (port=0x7f01b13c8f60) at ports.c:963
> #11 0x00007f01cbb4d7fd in deval (x=<optimized out>, x@entry=0x7f01bed8a210, 
> env=<optimized out>, env@entry=0x7f01b13c8f40) at eval.c:4232
> #12 0x00007f01cbb4c1c3 in deval (x=0x7f01bed8a1d0, 
> env=env@entry=0x7f01b13c8f40) at eval.c:4212
> #13 0x00007f01cbb4d3e7 in deval (x=0x7f01bed8a190, 
> env=env@entry=0x7f01b13c8f40) at eval.c:3591
> #14 0x00007f01cbb4d587 in deval (x=0x7f01bed89e00, x@entry=0x7f01bed862f0, 
> env=0x7f01b13c8f40, env@entry=0x7f01b13c9130) at eval.c:3648
> #15 0x00007f01cbb4cbbf in deval (x=0x7f01bed86010, x@entry=0x7f01bed818a0, 
> env=0x7f01b13c9130, env@entry=0x7f01b13c92c0) at eval.c:3469
> #16 0x00007f01cbb4bba4 in scm_dapply (proc=0x7f01beb47ff0, arg1=<optimized 
> out>, args=0x7f01b13c92c0) at eval.c:5012
> #17 0x00007f01c1096c1a in scm_srfi1_map (proc=0x7f01b13c9b70, 
> arg1=0x7f01b13c9be0, args=<optimized out>) at srfi-1.c:1443

Huh.  Maybe the file is renamed before Guile lets go of it?  Or it may
be a buffer overflow in Guile's input handling.

-- 
David Kastrup