bug#26936: grub_cmd_set_date test sometimes fail

[ludo@gnu.org (Ludovic Courtès)]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I've been encountering this test failure a couple times (3 out of 4 last
> build I've tried) recently on my GuixSD x86_64 system when building grub
> version 2.02.
>
> This test failure is not deterministic. The Guix automated build farm
> has yet to stumble on that failure.

I can reproduce it after a few tries.  Upon failure, the
‘test-suite.log’ file reads:

--8<---------------cut here---------------start------------->8---
FAIL: grub_cmd_set_date
=======================

qemu-system-i386: Trying to execute code outside RAM or ROM at 0xff62f000
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

Test failed: 2017-06-02 19:03:48 Friday
--8<---------------cut here---------------end--------------->8---

If we add “set -x” in the ‘grub-shell’ script, which is used by the
test, we see that it invokes QEMU like this:

--8<---------------cut here---------------start------------->8---
+ ./grub-mkrescue --output=/tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t8 --override-directory=./grub-core --rom-directory=/tmp/guix-build-grub-2.02.drv-0/tmp.d2FE5o8cWd --locale-directory=./po --themes-directory=./themes /boot/grub/grub.cfg=/tmp/guix-build-grub-2.02.drv-0/tmp.IxQUpfc7pT /boot/grub/testcase.cfg=/tmp/guix-build-grub-2.02.drv-0/tmp.v4GOg503yw
+ '[' xcd = xhd ']'
+ '[' xcd = xcd ']'
+ '[' i386-pc = arm64-efi ']'
+ '[' i386-pc = arm-efi ']'
+ '[' i386-pc = powerpc-ieee1275 ']'
+ device='cdrom '
+ bootdev='-boot d'
+ '[' xcd = xfd ']'
+ '[' xcd = xqemu ']'
+ '[' xcd = xmipsel_qemu ']'
+ '[' xcd = xmipsel_fulong2e ']'
+ '[' xcd = xmips_qemu ']'
+ '[' xcd = xcoreboot ']'
+ '[' i386-pc = mipsel-arc ']'
+ '[' xcd = xnet ']'
+ '[' xcd = xemu ']'
+ timeout -s KILL 60 qemu-system-i386 -nographic -monitor file:/dev/null -serial file:/dev/stdout -cdrom /tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t8 -boot d
--8<---------------cut here---------------end--------------->8---

It would seem that the test uses unique files, which would rule out the
possibility of a race condition when running tests with -jN.

However, running “make check -j20” led to another failure, in
‘grub_cmd_sleep’:

--8<---------------cut here---------------start------------->8---
Interval not in range 1496434911-1496434898 != 10
--8<---------------cut here---------------end--------------->8---

All in all, I’m tempted to think this has to do with running the tests
in parallel.

As a stop-gap measure, I’ve committed a change to run tests
sequentially.  With this “guix build grub --rounds=5” passes for on my
x86_64 laptop.  Let’s reopen the bug if we find that’s not enough.

Ludo’.