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

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

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.