[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50902: 28.0.50; emacs-module-tests time out
From: |
Philipp Stephani |
Subject: |
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@gmx.de>:
>
> Michael Albinus <michael.albinus@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)?
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/08
- bug#50902: 28.0.50; emacs-module-tests time out, Philipp Stephani, 2021/10/09
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/11
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/18
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/25
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/31
- bug#50902: 28.0.50; emacs-module-tests time out, Philipp Stephani, 2021/10/31
- bug#50902: 28.0.50; emacs-module-tests time out, Michael Albinus, 2021/10/31
- bug#50902: 28.0.50; emacs-module-tests time out,
Philipp Stephani <=