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 <m...@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
