bug#50902: 28.0.50; emacs-module-tests time out

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Hi,

on emba.gnu.org, emacs-module-tests time out. See for example
<https://emba.gnu.org/emacs/emacs/-/jobs/29103/raw>.

Best regards, Michael.


In GNU Emacs 28.0.50 (build 29, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-08-22 built on gandalf
Repository revision: 1afe59f7f888fd80e9bbad502d96e5e2ee9feb4c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8

Major mode: Group

Minor modes in effect:
  async-bytecomp-package-mode: t
  erc-notify-mode: t
  erc-notifications-mode: t
  recentf-mode: t
  gnus-undo-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  delete-selection-mode: t
  icomplete-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/albinus/.emacs.d/elpa/magit-20210822.529/magit-section-pkg hides /home/albinus/.emacs.d/elpa/magit-section-20210819.1119/magit-section-pkg
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-autoloads hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-autoloads
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-pkg hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-pkg
/home/albinus/src/tramp/lisp/tramp-sh hides /usr/local/share/emacs/site-lisp/tramp-sh
/home/albinus/src/tramp/lisp/tramp-cmds hides /usr/local/share/emacs/site-lisp/tramp-cmds
/home/albinus/src/tramp/lisp/tramp-gvfs hides /usr/local/share/emacs/site-lisp/tramp-gvfs
/home/albinus/src/tramp/lisp/tramp-ftp hides /usr/local/share/emacs/site-lisp/tramp-ftp
/home/albinus/src/tramp/lisp/tramp-crypt hides /usr/local/share/emacs/site-lisp/tramp-crypt
/home/albinus/src/tramp/lisp/tramp-adb hides /usr/local/share/emacs/site-lisp/tramp-adb
/home/albinus/src/tramp/lisp/tramp hides /usr/local/share/emacs/site-lisp/tramp
/home/albinus/src/tramp/lisp/tramp-cache hides /usr/local/share/emacs/site-lisp/tramp-cache
/home/albinus/src/tramp/lisp/tramp-rclone hides /usr/local/share/emacs/site-lisp/tramp-rclone
/home/albinus/src/tramp/lisp/tramp-compat hides /usr/local/share/emacs/site-lisp/tramp-compat
/home/albinus/src/tramp/lisp/tramp-integration hides /usr/local/share/emacs/site-lisp/tramp-integration
/home/albinus/src/tramp/lisp/tramp-archive hides /usr/local/share/emacs/site-lisp/tramp-archive
/home/albinus/src/tramp/lisp/tramp-sudoedit hides /usr/local/share/emacs/site-lisp/tramp-sudoedit
/home/albinus/src/tramp/lisp/tramp-loaddefs hides /usr/local/share/emacs/site-lisp/tramp-loaddefs
/home/albinus/src/tramp/lisp/tramp-uu hides /usr/local/share/emacs/site-lisp/tramp-uu
/home/albinus/src/tramp/lisp/tramp-smb hides /usr/local/share/emacs/site-lisp/tramp-smb
/home/albinus/src/tramp/lisp/trampver hides /usr/local/share/emacs/site-lisp/trampver
/home/albinus/.emacs.d/elpa/auth-source-pass-20210210.1908/auth-source-pass hides /usr/local/share/emacs/28.0.50/lisp/auth-source-pass
/home/albinus/.emacs.d/elpa/transient-20210819.2118/transient hides /usr/local/share/emacs/28.0.50/lisp/transient
~/lisp/dbus hides /usr/local/share/emacs/28.0.50/lisp/net/dbus
/home/albinus/src/tramp/lisp/tramp-sh hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-sh
/home/albinus/src/tramp/lisp/tramp-fuse hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-fuse
/home/albinus/src/tramp/lisp/tramp-ftp hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-ftp
/home/albinus/src/tramp/lisp/tramp hides /usr/local/share/emacs/28.0.50/lisp/net/tramp
/home/albinus/src/tramp/lisp/tramp-cache hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-cache
/home/albinus/src/tramp/lisp/tramp-uu hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-uu
/home/albinus/src/tramp/lisp/tramp-rclone hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-rclone
/home/albinus/src/tramp/lisp/tramp-integration hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-integration
/home/albinus/src/tramp/lisp/tramp-archive hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-archive
/home/albinus/src/tramp/lisp/tramp-adb hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-adb
/home/albinus/src/tramp/lisp/tramp-cmds hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-cmds
/home/albinus/src/tramp/lisp/tramp-compat hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-compat
/home/albinus/src/tramp/lisp/tramp-sudoedit hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-sudoedit
/home/albinus/src/tramp/lisp/tramp-gvfs hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-gvfs
/home/albinus/src/tramp/lisp/tramp-loaddefs hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-loaddefs
/home/albinus/src/tramp/lisp/tramp-crypt hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-crypt
/home/albinus/src/tramp/lisp/tramp-smb hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-smb
/home/albinus/src/tramp/lisp/trampver hides /usr/local/share/emacs/28.0.50/lisp/net/trampver
/home/albinus/src/tramp/lisp/tramp-sshfs hides /usr/local/share/emacs/28.0.50/lisp/net/tramp-sshfs

Features:
(shadow emacsbug epa-file helm-bookmark helm-net helm-adaptive helm-info
helm-utils helm-types helm-help helm async-bytecomp helm-global-bindings
helm-easymenu helm-source helm-multi-match helm-lib async em-xtra
em-unix em-tramp em-term em-script em-prompt em-ls em-hist em-pred
em-glob em-cmpl em-basic em-banner em-alias eshell xwidget mh-e
mh-compat mh-buffers mh-loaddefs erc-notify erc-networks
erc-desktop-notifications erc-match notifications erc-goodies erc
erc-backend erc-loaddefs so-long novice js imenu descr-text
tramp-archive thai-util thai-word flyspell ispell expand cl-indent
finder-inf package-x autoconf autoconf-mode ffap rect tramp-sudoedit
tramp-smb plstore debbugs-browse benchmark canlock gnus-eform nnfolder
rfc2104 auth-source-tests secrets dockerfile-mode cus-start cus-load
recentf tree-widget loadhist ediff-ptch vc-annotate gnus-draft
markdown-mode edebug make-mode sh-script smie executable texinfo
texinfo-loaddefs cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs rcirc tramp-gvfs zeroconf find-dired
emba glab ghub-graphql treepy gsexp ghub let-alist conf-mode
magit-process with-editor server magit-mode transient magit-git
magit-section tramp-theme em-dirs esh-var esh-mode esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util reveal
ange-ftp tramp-ftp mule-diag bookmark magit-utils cl-print yaml-mode
shortdoc help-fns radix-tree grep tramp-tests tramp-cmds trace ert-x ert
pp debug backtrace ediff-vers tramp-adb log-view ediff ediff-merg
ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util
whitespace mule-util smerge-mode diff autorevert filenotify
bug-reference misearch multi-isearch compile log-edit pcvs-util vc-mtn
vc-hg vc-git diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-dir
ewoc dired-aux mailalias gnus-fun nndoc gnus-dup crm debbugs-gnu add-log
debbugs soap-client warnings rng-xsd rng-dt rng-util xsd-regexp
time-stamp shr-color color timezone org-element avl-tree generator
ol-eww eww xdg url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp org-table
org-loaddefs find-func cal-menu calendar cal-loaddefs flow-fill url-http
url-gw url-auth gnus-gravatar gravatar dns url-cache sort gnus-cite
smiley mm-archive mail-extr gnus-bcklg gnus-async cl-extra help-mode qp
gnus-ml pop3 utf-7 nndraft nnmh nnml gnutls network-stream nsm
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig gnus-cache gnus-sum shr
kinsoku svg dom nnnil smtpmail sendmail gnus-demon nntp gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rmc
puny rfc822 mml mml-sec epa derived epg epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win
gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
text-property-search mail-utils mm-util mail-prsvr wid-edit edmacro
kmacro face-remap ob-shell ob ob-tangle ol org-src ob-ref ob-lob
ob-table ob-exp ob-comint ob-core ob-eval org-keys org-compat advice
org-macs vc vc-dispatcher cperl-mode rx facemenu time tramp-sh
docker-tramp kubernetes-tramp tramp-cache lxc-tramp lxd-tramp
vagrant-tramp dash term disp-table ehelp tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete comint ansi-color
ring parse-time iso8601 time-date ls-lisp format-spec delsel ido
jka-compr icomplete paren dired dired-loaddefs info package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 2527082 331927)
 (symbols 48 74754 14)
 (strings 32 477213 45075)
 (string-bytes 1 40191545)
 (vectors 16 128427)
 (vector-slots 8 2835046 290984)
 (floats 8 796 10064)
 (intervals 56 193281 9004)
 (buffers 992 457))

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi,

> on emba.gnu.org, emacs-module-tests time out.

The log file contains

--8<---------------cut here---------------start------------->8---
Running 38 tests (2021-10-08 04:35:34+0000, selector `(not (or (tag :unstable) (tag :nativecomp)))')
   passed   1/38  emacs-module-tests/interleaved-threads (0.000996 sec)
   passed   2/38  mod-test-add-nanosecond/invalid (0.000242 sec)
   passed   3/38  mod-test-add-nanosecond/nil (0.000117 sec)
   passed   4/38  mod-test-add-nanosecond/valid (0.000522 sec)
   passed   5/38  mod-test-double (0.000357 sec)
   passed   6/38  mod-test-globref-free-test (0.000120 sec)
   passed   7/38  mod-test-globref-make-test (0.023353 sec)
   passed   8/38  mod-test-globref-reordered (0.000132 sec)
   passed   9/38  mod-test-make-string/empty (0.000160 sec)
   passed  10/38  mod-test-make-string/nonempty (0.000348 sec)
   passed  11/38  mod-test-nanoseconds (0.000654 sec)
   passed  12/38  mod-test-non-local-exit-funcall-normal (0.000135 sec)
   passed  13/38  mod-test-non-local-exit-funcall-signal (0.000165 sec)
   passed  14/38  mod-test-non-local-exit-funcall-throw (0.000132 sec)
   passed  15/38  mod-test-non-local-exit-signal-test (0.230399 sec)
   passed  16/38  mod-test-non-local-exit-throw-test (0.000115 sec)
   passed  17/38  mod-test-sleep-until (0.218033 sec)
   passed  18/38  mod-test-string-a-to-b-test (0.000160 sec)
   passed  19/38  mod-test-sum-docstring (0.000142 sec)
   passed  20/38  mod-test-sum-test (0.000398 sec)
   passed  21/38  mod-test-userptr-fun-test (0.000219 sec)
   passed  22/38  mod-test-vector-test (0.021364 sec)
   passed  23/38  module--func-arity (0.000202 sec)
   passed  24/38  module--help-function-arglist (0.000273 sec)
--8<---------------cut here---------------end--------------->8---

So I suspect the timeout happens in module--test-assertions--call-emacs-from-gc.
Philipp, does this tell you anything?

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Philipp Stephani]

Am Fr., 8. Okt. 2021 um 13:45 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Michael Albinus <michael.albinus@gmx.de> writes:
>
> Hi,
>
> > on emba.gnu.org, emacs-module-tests time out.
>
> The log file contains
>
> --8<---------------cut here---------------start------------->8---
> Running 38 tests (2021-10-08 04:35:34+0000, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>    passed   1/38  emacs-module-tests/interleaved-threads (0.000996 sec)
>    passed   2/38  mod-test-add-nanosecond/invalid (0.000242 sec)
>    passed   3/38  mod-test-add-nanosecond/nil (0.000117 sec)
>    passed   4/38  mod-test-add-nanosecond/valid (0.000522 sec)
>    passed   5/38  mod-test-double (0.000357 sec)
>    passed   6/38  mod-test-globref-free-test (0.000120 sec)
>    passed   7/38  mod-test-globref-make-test (0.023353 sec)
>    passed   8/38  mod-test-globref-reordered (0.000132 sec)
>    passed   9/38  mod-test-make-string/empty (0.000160 sec)
>    passed  10/38  mod-test-make-string/nonempty (0.000348 sec)
>    passed  11/38  mod-test-nanoseconds (0.000654 sec)
>    passed  12/38  mod-test-non-local-exit-funcall-normal (0.000135 sec)
>    passed  13/38  mod-test-non-local-exit-funcall-signal (0.000165 sec)
>    passed  14/38  mod-test-non-local-exit-funcall-throw (0.000132 sec)
>    passed  15/38  mod-test-non-local-exit-signal-test (0.230399 sec)
>    passed  16/38  mod-test-non-local-exit-throw-test (0.000115 sec)
>    passed  17/38  mod-test-sleep-until (0.218033 sec)
>    passed  18/38  mod-test-string-a-to-b-test (0.000160 sec)
>    passed  19/38  mod-test-sum-docstring (0.000142 sec)
>    passed  20/38  mod-test-sum-test (0.000398 sec)
>    passed  21/38  mod-test-userptr-fun-test (0.000219 sec)
>    passed  22/38  mod-test-vector-test (0.021364 sec)
>    passed  23/38  module--func-arity (0.000202 sec)
>    passed  24/38  module--help-function-arglist (0.000273 sec)
> --8<---------------cut here---------------end--------------->8---
>
> So I suspect the timeout happens in module--test-assertions--call-emacs-from-gc.
> Philipp, does this tell you anything?
>


Not really. That test uses the module assertion functionality to abort
Emacs on some invalid usage patterns. It starts a subprocess which
should quickly call abort().
Would it be possible to capture a core dump or similar while the test
is hanging and analyze it with a debugger?

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Philipp Stephani <p.stephani2@gmail.com> 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.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

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.
[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.

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.
[New LWP 18947]
Failed to read a valid object file image from memory.
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.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Philipp,

> 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've tried now to run the test interactively, after log in to the docker
container:

--8<---------------cut here---------------start------------->8---
root@2499288dd2cf:/checkout# make -C test emacs-module-tests
make: Entering directory '/checkout/test'
make[1]: Entering directory '/checkout/test'
  GEN      src/emacs-module-tests.log
Running 38 tests (2021-10-25 12:52:58+0000, selector `(not (or (tag :unstable) (tag :nativecomp)))')
   passed   1/38  emacs-module-tests/interleaved-threads (0.006767 sec)
   passed   2/38  mod-test-add-nanosecond/invalid (0.000289 sec)
   passed   3/38  mod-test-add-nanosecond/nil (0.000123 sec)
   passed   4/38  mod-test-add-nanosecond/valid (0.000579 sec)
   passed   5/38  mod-test-double (0.000302 sec)
   passed   6/38  mod-test-globref-free-test (0.000150 sec)
   passed   7/38  mod-test-globref-make-test (0.055301 sec)
   passed   8/38  mod-test-globref-reordered (0.000733 sec)
   passed   9/38  mod-test-make-string/empty (0.000503 sec)
   passed  10/38  mod-test-make-string/nonempty (0.000600 sec)
   passed  11/38  mod-test-nanoseconds (0.000774 sec)
   passed  12/38  mod-test-non-local-exit-funcall-normal (0.000384 sec)
   passed  13/38  mod-test-non-local-exit-funcall-signal (0.000350 sec)
   passed  14/38  mod-test-non-local-exit-funcall-throw (0.000381 sec)
   passed  15/38  mod-test-non-local-exit-signal-test (0.368848 sec)
   passed  16/38  mod-test-non-local-exit-throw-test (0.006130 sec)
   passed  17/38  mod-test-sleep-until (0.203062 sec)
   passed  18/38  mod-test-string-a-to-b-test (0.000668 sec)
   passed  19/38  mod-test-sum-docstring (0.000253 sec)
   passed  20/38  mod-test-sum-test (0.000665 sec)
   passed  21/38  mod-test-userptr-fun-test (0.000466 sec)
   passed  22/38  mod-test-vector-test (0.009041 sec)
   passed  23/38  module--func-arity (0.004958 sec)
   passed  24/38  module--help-function-arglist (0.000791 sec)
2021 Oct 25 08:52:59 emba kernel BUG at /build/linux-Pv5wqf/linux-4.4.0/mm/memory.c:3214!
2021 Oct 25 08:52:59 emba RIP  [<ffffffff811cd1ae>] handle_mm_fault+0x13de/0x1b80
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Philipp,

>> 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've tried now to run the test interactively, after log in to the docker
> container:

No reaction. So I have disabled this test file on emba.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Philipp Stephani]

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

[Philipp Stephani]

Am Mo., 25. Okt. 2021 um 14:57 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Michael Albinus <michael.albinus@gmx.de> writes:
>
> Hi Philipp,
>
> > 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've tried now to run the test interactively, after log in to the docker
> container:
>
> --8<---------------cut here---------------start------------->8---
> root@2499288dd2cf:/checkout# make -C test emacs-module-tests
> make: Entering directory '/checkout/test'
> make[1]: Entering directory '/checkout/test'
>   GEN      src/emacs-module-tests.log
> Running 38 tests (2021-10-25 12:52:58+0000, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>    passed   1/38  emacs-module-tests/interleaved-threads (0.006767 sec)
>    passed   2/38  mod-test-add-nanosecond/invalid (0.000289 sec)
>    passed   3/38  mod-test-add-nanosecond/nil (0.000123 sec)
>    passed   4/38  mod-test-add-nanosecond/valid (0.000579 sec)
>    passed   5/38  mod-test-double (0.000302 sec)
>    passed   6/38  mod-test-globref-free-test (0.000150 sec)
>    passed   7/38  mod-test-globref-make-test (0.055301 sec)
>    passed   8/38  mod-test-globref-reordered (0.000733 sec)
>    passed   9/38  mod-test-make-string/empty (0.000503 sec)
>    passed  10/38  mod-test-make-string/nonempty (0.000600 sec)
>    passed  11/38  mod-test-nanoseconds (0.000774 sec)
>    passed  12/38  mod-test-non-local-exit-funcall-normal (0.000384 sec)
>    passed  13/38  mod-test-non-local-exit-funcall-signal (0.000350 sec)
>    passed  14/38  mod-test-non-local-exit-funcall-throw (0.000381 sec)
>    passed  15/38  mod-test-non-local-exit-signal-test (0.368848 sec)
>    passed  16/38  mod-test-non-local-exit-throw-test (0.006130 sec)
>    passed  17/38  mod-test-sleep-until (0.203062 sec)
>    passed  18/38  mod-test-string-a-to-b-test (0.000668 sec)
>    passed  19/38  mod-test-sum-docstring (0.000253 sec)
>    passed  20/38  mod-test-sum-test (0.000665 sec)
>    passed  21/38  mod-test-userptr-fun-test (0.000466 sec)
>    passed  22/38  mod-test-vector-test (0.009041 sec)
>    passed  23/38  module--func-arity (0.004958 sec)
>    passed  24/38  module--help-function-arglist (0.000791 sec)
> 2021 Oct 25 08:52:59 emba kernel BUG at /build/linux-Pv5wqf/linux-4.4.0/mm/memory.c:3214!
> 2021 Oct 25 08:52:59 emba RIP  [<ffffffff811cd1ae>] handle_mm_fault+0x13de/0x1b80
> --8<---------------cut here---------------end--------------->8---
>

That looks even weirder. Does the "kernel BUG" line indicate an actual
Linux kernel bug? That could at least explain the weird behavior that
we see in userspace.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Philipp Stephani <p.stephani2@gmail.com> writes:

Hi Philipp,

> That looks even weirder. Does the "kernel BUG" line indicate an actual
> Linux kernel bug? That could at least explain the weird behavior that
> we see in userspace.

The docker containers are still available on emba. Pls send me your
public ssh key, I'll give you access to emba.gnu.org then + instructions
how to enter the docker container and run your own tests.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Philipp]

> Am 31.10.2021 um 19:32 schrieb Michael Albinus <michael.albinus@gmx.de>:
> 
> Philipp Stephani <p.stephani2@gmail.com> writes:
> 
> Hi Philipp,
> 
>> That looks even weirder. Does the "kernel BUG" line indicate an actual
>> Linux kernel bug? That could at least explain the weird behavior that
>> we see in userspace.
> 
> The docker containers are still available on emba. Pls send me your
> public ssh key, I'll give you access to emba.gnu.org then + instructions
> how to enter the docker container and run your own tests.

I've played around with the docker containers a bit, but couldn't find anything interesting.  Given the error message, I'm 99% sure it's a kernel bug (which gets triggered when raise(SIGABRT) is called), so maybe it would be best to report this to the Linux kernel folks?
BTW, a more minimal command to reproduce it is
# /checkout/src/emacs -batch -Q -module-assertions -eval "(progn (setq attempt-orderly-shutdown-on-fatal-signal nil) (require 'mod-test \"/checkout/test/src/emacs-module-resources/mod-test\") (mod-test-invalid-finalizer) (garbage-collect))"

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Philipp <p.stephani2@gmail.com> writes:

Hi Philipp,

>>> That looks even weirder. Does the "kernel BUG" line indicate an actual
>>> Linux kernel bug? That could at least explain the weird behavior that
>>> we see in userspace.
>>
>> The docker containers are still available on emba. Pls send me your
>> public ssh key, I'll give you access to emba.gnu.org then + instructions
>> how to enter the docker container and run your own tests.
>
> I've played around with the docker containers a bit, but couldn't find
> anything interesting.  Given the error message, I'm 99% sure it's a
> kernel bug (which gets triggered when raise(SIGABRT) is called), so
> maybe it would be best to report this to the Linux kernel folks?
> BTW, a more minimal command to reproduce it is # /checkout/src/emacs
> -batch -Q -module-assertions -eval "(progn (setq
> attempt-orderly-shutdown-on-fatal-signal nil) (require 'mod-test
> \"/checkout/test/src/emacs-module-resources/mod-test\")
> (mod-test-invalid-finalizer) (garbage-collect))"

Thanks you for the analysis. Well, I don't know too much about dynamic
modules, so I'd let it to you whether to report a kernel bug.

Could you add a comment to the respective tests in
emacs-module-tests.el, and skip them if they run on emba?

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Philipp Stephani]

Am Fr., 12. Nov. 2021 um 16:08 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Philipp <p.stephani2@gmail.com> writes:
>
> Hi Philipp,
>
> >>> That looks even weirder. Does the "kernel BUG" line indicate an actual
> >>> Linux kernel bug? That could at least explain the weird behavior that
> >>> we see in userspace.
> >>
> >> The docker containers are still available on emba. Pls send me your
> >> public ssh key, I'll give you access to emba.gnu.org then + instructions
> >> how to enter the docker container and run your own tests.
> >
> > I've played around with the docker containers a bit, but couldn't find
> > anything interesting.  Given the error message, I'm 99% sure it's a
> > kernel bug (which gets triggered when raise(SIGABRT) is called), so
> > maybe it would be best to report this to the Linux kernel folks?
> > BTW, a more minimal command to reproduce it is # /checkout/src/emacs
> > -batch -Q -module-assertions -eval "(progn (setq
> > attempt-orderly-shutdown-on-fatal-signal nil) (require 'mod-test
> > \"/checkout/test/src/emacs-module-resources/mod-test\")
> > (mod-test-invalid-finalizer) (garbage-collect))"
>
> Thanks you for the analysis. Well, I don't know too much about dynamic
> modules, so I'd let it to you whether to report a kernel bug.
>
> Could you add a comment to the respective tests in
> emacs-module-tests.el, and skip them if they run on emba?

How about updating the Emba machine first and checking whether the
problem still appears? According to /etc/lsb-release the machine runs
Trisquel 8, which is outdated according to
https://trisquel.info/en/trisquel-80-lts-flidas. I'd say we should
first try updating to Trisquel 9.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Philipp Stephani <p.stephani2@gmail.com> writes:

Hi Philipp,

>> > I've played around with the docker containers a bit, but couldn't find
>> > anything interesting.  Given the error message, I'm 99% sure it's a
>> > kernel bug (which gets triggered when raise(SIGABRT) is called), so
>> > maybe it would be best to report this to the Linux kernel folks?
>> > BTW, a more minimal command to reproduce it is # /checkout/src/emacs
>> > -batch -Q -module-assertions -eval "(progn (setq
>> > attempt-orderly-shutdown-on-fatal-signal nil) (require 'mod-test
>> > \"/checkout/test/src/emacs-module-resources/mod-test\")
>> > (mod-test-invalid-finalizer) (garbage-collect))"
>>
>> Thanks you for the analysis. Well, I don't know too much about dynamic
>> modules, so I'd let it to you whether to report a kernel bug.
>>
>> Could you add a comment to the respective tests in
>> emacs-module-tests.el, and skip them if they run on emba?
>
> How about updating the Emba machine first and checking whether the
> problem still appears? According to /etc/lsb-release the machine runs
> Trisquel 8, which is outdated according to
> https://trisquel.info/en/trisquel-80-lts-flidas. I'd say we should
> first try updating to Trisquel 9.

The tests run in a docker container, which is derived as

FROM debian:stretch as emacs-base

(see test/infra/Dockerfile.emba). I don't know docker good enough to
know which kernel is used, the one from the host, or the on from the
container image.

Furthermore, it isn't only emba.gnu.org, but also emba-runner.gnu.org,
which is a second machine which must be in sync. For both machines I
have no rights to upgrade or so; this in done by FSF admins.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Philipp]

> Am 14.11.2021 um 15:48 schrieb Michael Albinus <michael.albinus@gmx.de>:
> 
> Philipp Stephani <p.stephani2@gmail.com> writes:
> 
> Hi Philipp,
> 
>>>> I've played around with the docker containers a bit, but couldn't find
>>>> anything interesting.  Given the error message, I'm 99% sure it's a
>>>> kernel bug (which gets triggered when raise(SIGABRT) is called), so
>>>> maybe it would be best to report this to the Linux kernel folks?
>>>> BTW, a more minimal command to reproduce it is # /checkout/src/emacs
>>>> -batch -Q -module-assertions -eval "(progn (setq
>>>> attempt-orderly-shutdown-on-fatal-signal nil) (require 'mod-test
>>>> \"/checkout/test/src/emacs-module-resources/mod-test\")
>>>> (mod-test-invalid-finalizer) (garbage-collect))"
>>> 
>>> Thanks you for the analysis. Well, I don't know too much about dynamic
>>> modules, so I'd let it to you whether to report a kernel bug.
>>> 
>>> Could you add a comment to the respective tests in
>>> emacs-module-tests.el, and skip them if they run on emba?
>> 
>> How about updating the Emba machine first and checking whether the
>> problem still appears? According to /etc/lsb-release the machine runs
>> Trisquel 8, which is outdated according to
>> https://trisquel.info/en/trisquel-80-lts-flidas. I'd say we should
>> first try updating to Trisquel 9.
> 
> The tests run in a docker container, which is derived as
> 
> FROM debian:stretch as emacs-base
> 
> (see test/infra/Dockerfile.emba). I don't know docker good enough to
> know which kernel is used, the one from the host, or the on from the
> container image.

According to https://superuser.com/a/889474 it's always the host kernel.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Philipp <p.stephani2@gmail.com> writes:

Hi Philipp,

>>> How about updating the Emba machine first and checking whether the
>>> problem still appears? According to /etc/lsb-release the machine runs
>>> Trisquel 8, which is outdated according to
>>> https://trisquel.info/en/trisquel-80-lts-flidas. I'd say we should
>>> first try updating to Trisquel 9.
>>
>> The tests run in a docker container, which is derived as
>>
>> FROM debian:stretch as emacs-base
>>
>> (see test/infra/Dockerfile.emba). I don't know docker good enough to
>> know which kernel is used, the one from the host, or the on from the
>> container image.
>
> According to https://superuser.com/a/889474 it's always the host kernel.

Yes.

However, I'm still skeptic whether we should upgrade emba because of
emacs-module-tests. Instead, I have tagged module--test-assertions--* as
:unstable on emba, and I have reenabled emacs-module-tests there. Let's
see how it goes. If the tests run through, I will close this bug report.

Best regards, Michael.

bug#50902: 28.0.50; emacs-module-tests time out

[Michael Albinus]

Version: 29.1

Hi Philipp,

> However, I'm still skeptic whether we should upgrade emba because of
> emacs-module-tests. Instead, I have tagged module--test-assertions--* as
> :unstable on emba, and I have reenabled emacs-module-tests there. Let's
> see how it goes. If the tests run through, I will close this bug report.

The tests have passed on emba, so I'm closing this bug.

Best regards, Michael.