☠ Buildbot (GNU Toolchain): elfutils - failed test (failure) (master)

[Mark Wielaard]

Hi,

On Sat, May 28, 2022 at 09:15:30AM +0000, builder--- via Elfutils-devel wrote:
> A new failure has been detected on builder elfutils-centos-x86_64 while building elfutils.
> 
> Full details are available at:
>     https://builder.sourceware.org/buildbot/#builders/39/builds/33
> 
> Build state: failed test (failure)
> Revision: b8713b3fd0617415c76df8c9da70f8e2f26d3134
> Worker: centos-x86_64
> Build Reason: (unknown)
> Blamelist: Mark Wielaard <mark@klomp.org>
> 
> - 7: make check ( failure )
>     Logs:
>         - stdio: https://builder.sourceware.org/buildbot/#builders/39/builds/33/steps/7/logs/stdio
>         - test-suite.log: https://builder.sourceware.org/buildbot/#builders/39/builds/33/steps/7/logs/test-suite_log

Well that is interesting, fails at the same point:

/srv/buildbot/worker/elfutils-centos-x86_64/build/tests/run-debuginfod-federation-metrics.sh: line 198: 23793 Aborted                 env LD_LIBRARY_PATH=$ldpath ${abs_builddir}/../debuginfod/debuginfod $VERBOSE -d ${DB} -F -U -t0 -g0 -p $PORT1 L D F > vlog$PORT1 2>&1

Still no core :{

Retrying with ulimit -c unlimited...

O! It failed again, now with core

(gdb) where
#0  0x00007f4d528be387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007f4d528bfa78 in __GI_abort () at abort.c:90
#2  0x00007f4d53dfae1f in mhd_panic_std (cls=<optimized out>, file=<optimized out>, 
    line=<optimized out>, reason=<optimized out>) at daemon.c:117
#3  0x00007f4d53dfc69e in MHD_cleanup_connections (daemon=daemon@entry=0xdf38e0) at daemon.c:1826
#4  0x00007f4d53dfdf60 in MHD_run_from_select (daemon=daemon@entry=0xdf38e0, 
    read_fd_set=read_fd_set@entry=0x7f4d4c153c10, write_fd_set=write_fd_set@entry=0x7f4d4c153c90, 
    except_fd_set=except_fd_set@entry=0x7f4d4c153d10) at daemon.c:2014
#5  0x00007f4d53dfe1e9 in MHD_select (daemon=daemon@entry=0xdf38e0, may_block=may_block@entry=1)
    at daemon.c:2109
#6  0x00007f4d53dfe3b2 in MHD_select_thread (cls=0xdf38e0) at daemon.c:2632
#7  0x00007f4d53681ea5 in start_thread (arg=0x7f4d4c154700) at pthread_create.c:307
#8  0x00007f4d52986b0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

(gdb) 
#3  0x00007f4d53dfc69e in MHD_cleanup_connections (daemon=daemon@entry=0xdf38e0) at daemon.c:1826
1826		    MHD_PANIC ("close failed\n");
(gdb) list
1821		{
1822	#ifdef WINDOWS
1823		  SHUTDOWN (pos->socket_fd, SHUT_WR);
1824	#endif
1825		  if (0 != CLOSE (pos->socket_fd))
1826		    MHD_PANIC ("close failed\n");
1827		}
1828	      if (NULL != pos->addr)
1829		free (pos->addr);
1830	      free (pos);

Hohum. That does look like a bug in libmicrohttpd. Or do we manipulate
the socket_fd in any way?

Cheers,

Mark