ARM compilation via qemu binfmt - Assertion failure

ARM compilation via qemu binfmt - Assertion failure

[Danny Milosavljevic]

Hi ng0,

On Tue, 06 Feb 2018 10:33:56 +0000
ng0@n0.is wrote:

> recently I've read about slow but native compiling of ARM on qemu.

Unfortunately, there's a (pretty reproducible) problem with it.

guix-master/guix $ ./pre-inst-env guix system disk-image --system=armhf-linux -e "(@ (gnu system install) installation-os)"
[... building grub-2.02 ...]
phase `configure' succeeded after 821.8 seconds
starting phase `patch-generated-file-shebangs'
patch-makefile-SHELL: ./po/Makefile: changing `SHELL' from `/bin/sh' to `/gnu/st[...]
phase `patch-generated-file-shebangs' succeeded after 14.6 seconds
starting phase `build'
bison -d -p grub_script_yy -b grub_script ./grub-core/script/parser.y
flex -o grub_script.yy.c --header-file=grub_script.yy.h ./grub-core/script/yylex[...]
bison: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed

This is only fixed in glibc 2.27 (not in core-updates).

The fix is:

https://sourceware.org/bugzilla/show_bug.cgi?id=22273
diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
index dea1650..f02ac19 100644
--- a/sysdeps/unix/sysv/linux/spawni.c
+++ b/sysdeps/unix/sysv/linux/spawni.c
@@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
   if (new_pid > 0)
     {
       ec = args.err;
-      assert (ec >= 0);
       if (ec != 0)
-         __waitpid (new_pid, NULL, 0);
+       {
+         /* It handles the unlikely case where the auxiliary vfork process
+            is killed before calling _exit or execve.  */
+         int status;
+         __waitpid (new_pid, &status, 0);
+         if (WIFSIGNALED (status))
+           ec = 0;
+       }
     }
   else
     ec = -new_pid;

Re: ARM compilation via qemu binfmt - Assertion failure

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> This is only fixed in glibc 2.27 (not in core-updates).

Should we upgrade glibc in core-updates, then?  Or is it better to do it
in the next core-updates cycle, to avoid still more unexpected breakage?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

It's too late in this cycle. Upgrading glibc would require a full
rebuild and would introduce new failures.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ARM compilation via qemu binfmt - Assertion failure

[Pjotr Prins]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

I think we should not update packages deep in the tree unless there is
a security patch. What we have now is well tested.

Pj.


-- 

bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Unfortunately, there's a (pretty reproducible) problem with it.
>
> guix-master/guix $ ./pre-inst-env guix system disk-image --system=armhf-linux -e "(@ (gnu system install) installation-os)"
> [... building grub-2.02 ...]
> phase `configure' succeeded after 821.8 seconds
> starting phase `patch-generated-file-shebangs'
> patch-makefile-SHELL: ./po/Makefile: changing `SHELL' from `/bin/sh' to `/gnu/st[...]
> phase `patch-generated-file-shebangs' succeeded after 14.6 seconds
> starting phase `build'
> bison -d -p grub_script_yy -b grub_script ./grub-core/script/parser.y
> flex -o grub_script.yy.c --header-file=grub_script.yy.h ./grub-core/script/yylex[...]
> bison: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed

[...]

> https://sourceware.org/bugzilla/show_bug.cgi?id=22273
> diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
> index dea1650..f02ac19 100644
> --- a/sysdeps/unix/sysv/linux/spawni.c
> +++ b/sysdeps/unix/sysv/linux/spawni.c
> @@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
>    if (new_pid > 0)
>      {
>        ec = args.err;
> -      assert (ec >= 0);
>        if (ec != 0)

Note that this is only a problem for code that uses the ‘posix_spawn’
interface, such as Bison in the example above.

In practice that interface is rarely used, which is probably why I never
hit that assertion before.

Ludo’.