GNU bug report logs - #50902
28.0.50; emacs-module-tests time out

Previous Next

Full log

Message #26 received at 50902 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Philipp Stephani <phst <at> google.com>, 50902 <at> debbugs.gnu.org
Subject: Re: bug#50902: 28.0.50; emacs-module-tests time out
Date: Sun, 31 Oct 2021 19:08:55 +0100

Am Mo., 18. Okt. 2021 um 16:09 Uhr schrieb Michael Albinus
<michael.albinus <at> gmx.de>:
>
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
> Hi Philipp,
>
> >> Would it be possible to capture a core dump or similar while the test
> >> is hanging and analyze it with a debugger?
> >
> > I'll try it.
>
> Finally, I've managed to create two core files, and to extract them from
> the container the Emacs test is running on emba.gnu.org. In order to
> create them, I've instrumented the Emacs call in test/Makefile.in with
> "timeout -s ABRT ${EMACS_TEST_TIMEOUT}", see commit ffff168d5f in
> master.
>
> The container on emba the tests are running is based on debian:stretch.
> /proc/sys/kernel/core_pattern in the container contains just the entry
> "core", meaning the core file is written into the current directory.
>
> The first core is written into Emacs' test directory:
>
> --8<---------------cut here---------------start------------->8---
> # pwd
> /checkout/src
> # gdb --core=../test/core
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> BFD: Warning: /checkout/src/../test/core is truncated: expected core file size >= 37511168, found: 33046528.

This looks weird. Is maybe the disk space in the container too small
to write a full coredump?

> [New LWP 18942]
> Failed to read a valid object file image from memory.
> Core was generated by `../src/emacs --module-assertions --no-init-file --no-site-file --no-site-lisp -'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x00007ffff6fa8fbf in ?? ()
> warning: File "/checkout/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> To enable execution of this file add
>         add-auto-load-safe-path /checkout/src/.gdbinit
> line to your configuration file "/root/.gdbinit".
> To completely disable this security protection add
>         set auto-load safe-path /
> line to your configuration file "/root/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
>         info "(gdb)Auto-loading safe path"
> (gdb) source .gdbinit
> .gdbinit:19: Error in sourced command file:
> No symbol table is loaded.  Use the "file" command.
> (gdb) bt
> No stack.
> (gdb)
> --8<---------------cut here---------------end--------------->8---
>
> This is obviously the Emacs call to test.

But why is there no stack? Is that maybe related to the "truncated
core file" message before?

>
> The other core file is located at /tmp/emacs-module-test2fEwyL, I guess
> this directory has been created by your test package. "gdb --core ..." tells us
>
> --8<---------------cut here---------------start------------->8---
> # gdb --core=/tmp/emacs-module-test2fEwyL/core
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> BFD: Warning: /tmp/emacs-module-test2fEwyL/core is truncated: expected core file size >= 16920576, found: 12492800.

Same problem here, it seems, though it's interesting that the expected
and found file sizes are so different.

> [New LWP 18947]
> Failed to read a valid object file image from memory.

This also looks like a problem.

> Core was generated by `/checkout/src/emacs -batch -Q -module-assertions -eval (setq w32-disable-abort-'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x00007ffff6fa8fbf in ?? ()
> warning: File "/checkout/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> To enable execution of this file add
>         add-auto-load-safe-path /checkout/src/.gdbinit
> line to your configuration file "/root/.gdbinit".
> To completely disable this security protection add
>         set auto-load safe-path /
> line to your configuration file "/root/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
>         info "(gdb)Auto-loading safe path"
> (gdb) source .gdbinit
> .gdbinit:19: Error in sourced command file:
> No symbol table is loaded.  Use the "file" command.
> (gdb) bt
> #0  0x00007ffff6fa8fbf in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffffffcf18
> (gdb)
> --8<---------------cut here---------------end--------------->8---
>
> Both outputs don't look too informative. What else can I do? Do you want
> to get the core files? Note, that I'm not fluent with gdb; precise
> instructions are needed.

I don't really know much about this situation either, sorry. I
wouldn't expect that the core files would be useful for me, because
they need to match the program file exactly.
Is there a way to run these tests locally (i.e. not on EMBA)?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.