localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed.

[JackieKu]

• A brief description
  When running locale-gen it always failed with the following assertion failure:

localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed.

This is because by default charmaps (/usr/share/i18n/charmaps) are gzipped and localedef invokes posix_spawn in order to decompress those files.

• Expected results
  No errors when running locale-gen with gzipped charmap files.

• Actual results (with terminal output if applicable)
  localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion ec >= 0' failed.`

• Your Windows build number
  15063

• Steps / All commands required to reproduce the error from a brand new installation

1. Edit the locale list at /etc/locale.gen.
2. Run `locale-gen' as root.

• Strace of the failing command
  None. This bug is easy to be reproduced and the line numbers are available.

• Required packages and commands to install
  glibc 2.25

[therealkenc]

It's only "easy to reproduce" if you are on 16.10. I went back to Xenial unfortunately, but wasn't hitting it at the time I looked in early March (see #1660 - message). Link a gist of sudo strace -ff locale-gen and someone can take a look.

[Pyrepenol]

The same error shows up when attempting to run Fish Shell on an alternative OS. Perhaps it's related somehow?

alwsl/alwsl#37

[therealkenc]

Almost certainly the same problem. Arch uses newer glibc etc. See for example #1578. Still no strace....

[skyem123]

While this is not for locale-gen... I got a very similar error for Ninja (and m4 while trying to compile a working strace), I am currently working on getting a friend to compile me a hopefully working version of strace on a real Linux system. (I'm using ALWSL, where strace is broken in a different way... bleeding edge is exciting!)

[skyem123]

Hopefully this helps... #1306 (comment)

[Christoph-Wagner]

For those who land here and don't know a lot about linux, unpacking the relevant file (e.g. gunzip --keep /usr/share/i18n/charmaps/UTF-8.gz) avoids the problem and locale-gen runs.

[therealkenc]

Okay let's do this one. The crux is the following from man clone(2):

       CLONE_VFORK (since Linux 2.2)
              If CLONE_VFORK is set, the execution of the calling process is
              suspended until the child releases its virtual memory
              resources via a call to execve(2) or _exit(2) (as with
              vfork(2)).

On WSL the caller isn't being suspended. Actual fail in glibc is here, which got introduced Sept 28th with this commit. Test case below, which is a variation on #1005. It can be run on Xenial. Get the 'Oops' path on WSL but not Real Linux. No strace because the syscalls all succeed; unlike #1005 it is behavioral.

/* clone-test.c */
#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/wait.h>
#include <signal.h>

#define STACK_SIZE 16364

struct posix_spawn_args
{
  char *hello;
  int err;
};

static int spawni_child(void *arguments) 
{
  struct posix_spawn_args *args = arguments;

  printf("child arg: %s -- sleeping\n", args->hello);
  sleep(1);
  args->err = 0;
  _exit(0);
  return 0;
}

int main(int argc, char *argv[]) 
{
  struct posix_spawn_args args;
  void** child_stack;
  pid_t new_pid;
  int ec;

  args.hello = "hello";
  args.err = -1;
  
  child_stack = (void **)malloc(STACK_SIZE);
  
  // clone is supposed to suspend calling thread 
  // until the child calls execve or _exit
  new_pid = clone(spawni_child, 
      child_stack + STACK_SIZE, 
      CLONE_VM|CLONE_VFORK|SIGCHLD, 
      &args);

  if (new_pid > 0) {
    printf("we should get here only after child called _exit()\n");
    if (args.err < 0) {
      printf("Oops -- args.err should be 0 because it was set in the child\n");
    }
    waitpid(new_pid, NULL, 0);
    printf("child finished doing it's thing\n");
  } else if (new_pid == -1) {
    printf("this path was fixed in #1005\n");
  }

  printf("exiting main\n");
  return 0;
}

[bronze51]

I unpacked the relevant file, ran locale-gen, but still got this error when installing gtkd from the AUR (on WSL). Is there another locale I need to set beyond en_US.UTF-8?

[skyem123]

The same thing also happens when I use clang, from what I can tell.

[derekyu56]

I ran into the same problem trying yocto project build in Ubuntu 16.04 in WSL:
`automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey [email protected]
and Alexandre Duret-Lutz [email protected].
AUTOV is 1
autoreconf: Entering directory .' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --system-acdir=/home/derekyu/poky/build/tmp/work/x86_64-linux/libtool-native/2.4.6-r0/recip e-sysroot-native/usr/share/aclocal/ -I /home/derekyu/poky/build/tmp/work/x86_64-linux/libtool-native/2.4.6-r0/libtool-2. 4.6/m4/ -I /home/derekyu/poky/build/tmp/work/x86_64-linux/libtool-native/2.4.6-r0/libtool-2.4.6/tests/ --force -I m4 m4: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion ec >= 0' failed.
m4: internal error detected; please report this bug to [email protected]: Aborted
autom4te: m4 failed with exit status: 2
aclocal: error: echo failed with exit status: 2`

Is there any get around in this issue?

[therealkenc]

@derekyu56 - That's somewhat curious, if you are on 16.04 (Xenial). What does m4 --version report? Also ldd --version. You should see m4 1.4.17 and glibc 2.23. The problem reported here shouldn't happen until glibc 2.24 or 2.25 (I never took the time to figure which, since it's academic either way).

[edit] I didn't pick up on 'yocto build'. If yocto ships m4 make sure get that binary's version, not the one from Ubuntu Xenial. And if the yocto m4 binary is statically linked, then pretty much all bets are off. The work-around would be to use Xenial's m4 with Xenial's 2.23 glibc.

[derekyu56]

Here are the version information:

m4 (GNU M4) 1.4.17
ldd (Ubuntu GLIBC 2.23-0ubuntu7) 2.23

I don't think Yocto shipped with m4.

[derekyu56]

Sorry, I was wrong. Yocto did shipped with m4 and it is version 1.4.18. I will see if I can replace it with the one from Xenial.

[therealkenc]

You can also try to find an older version of Yocto that uses glibc 2.23. [m4 isn't really the problem here.] In other words rather than "replace it with the one from Xenial", find a Yocto that is better aligned with the toolchain that ships with Xenial. Either way good luck.

[derekyu56]

Unfortunately, older version has different problems and I was not able to use that either. Thanks for the suggestion. I guess I will have to wait until this issue is resolved.

[vc12345679]

@Christoph-Wagner That exactly helps! THX dude.

[bobvanderlinden]

What is needed to get this actually fixed? The workarounds are fine for each use-case, but it those aren't permanent solutions. I'm running into this issue when using NixOS, which uses m4. My guess is that eventually LTS distros will also run into these issues.

[jstarks]

@matshch Stick with 16.04 LTS for now.

[TerrorJack]

@matshch I'm on insider 17025 and sticking on 17.04 for now, no problem so far.

[derekyu56]

Thanks, I will give a try.

…

On Mon, Oct 30, 2017 at 2:46 PM, Adam Oleksy ***@***.***> wrote: @derekyu56 <https://github.com/derekyu56> You can use newest yocto (e.g. rocko) on WSL without this problem. There is only one thing you have to do: git checkout ce7e0252c498c25c782e181283172591d3e8b76b -- meta/conf /distro/include/yocto-uninative.inc It changes version of the uninative package to the one which has glibc which works on WSL. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1878 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIE6Sx7OE79Y8T_MmQsFHcC-8EC6jV3Gks5sxhlzgaJpZM4M50nV> .

[derekyu56]

The yocto build still failed in rocko build with the git checkout. This time it did build 1031 packages, much better than before but it failed in: /home/derekyu/yocto/poky/meta/recipes-devtools/gcc/gcc-cross_7.2.bb: do_compile /home/derekyu/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.12.bb: do_package This is a different topic so I'll stop here. Thanks anyway.

…

On Tue, Oct 31, 2017 at 10:18 PM, Derek Yu ***@***.***> wrote: Thanks, I will give a try. On Mon, Oct 30, 2017 at 2:46 PM, Adam Oleksy ***@***.***> wrote: > @derekyu56 <https://github.com/derekyu56> You can use newest yocto (e.g. > rocko) on WSL without this problem. There is only one thing you have to do: > git checkout ce7e0252c498c25c782e181283172591d3e8b76b -- meta/conf > /distro/include/yocto-uninative.inc > It changes version of the uninative package to the one which has glibc > which works on WSL. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1878 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AIE6Sx7OE79Y8T_MmQsFHcC-8EC6jV3Gks5sxhlzgaJpZM4M50nV> > . >

[K900]

@jstarks is the fix supposed to be included in 17035? Doesn't look like it for me :(

[jstarks]

No :(. We've had some unfortunate delays getting WSL fixes into the insider builds lately. We'll get that unblocked as soon as we can.

[nstrelow]

Was this fixed in 17040 ?

[heldchen]

@nstrelow nope:

me@devbox:~$ sudo apt-mark unhold bash
Canceled hold on bash.
me@devbox:~$ sudo apt-get upgrade bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  bash
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 625 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu artful/main amd64 bash amd64 4.4-5ubuntu1 [625 kB]
Fetched 625 kB in 0s (1,948 kB/s)
(Reading database ... 38045 files and directories currently installed.)
Preparing to unpack .../bash_4.4-5ubuntu1_amd64.deb ...
preinst: ../sysdeps/unix/sysv/linux/spawni.c:368: __spawnix: Assertion `ec >= 0' failed.
dpkg: error processing archive /var/cache/apt/archives/bash_4.4-5ubuntu1_amd64.deb (--unpack):
 subprocess new pre-installation script was killed by signal (Aborted), core dumped
dmesg: read kernel buffer failed: Function not implemented
                                                          update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
Errors were encountered while processing:
 /var/cache/apt/archives/bash_4.4-5ubuntu1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
me@devbox:~$

[Brian-Perkins]

Windows Insider Build 17046 has improved CLONE_VFORK and CLONE_VM support.

[K900]

This is great news! Does this mean the behavior is fully compliant, or are there still incompatibilities left?

[heldchen]

Windows Insider Build 17046 has improved CLONE_VFORK and CLONE_VM support.

apt-get upgrade bash went through without the Assertion 'ec >= 0' failed error

[Brian-Perkins]

The behavior is not yet fully compatible. There are still some flags including CLONE_NEWUSER and CLONE_SIGHAND that do not work, and some supported flag combinations that either are not 100% compatible or haven't yet been verified to be. Some of these we are already looking at and others will be prioritized, as per usual, when interesting scenarios emerge involving them.

[glaubitz]

Just as a heads-up, this issue affects qemu-user as well:

dpkg: warning: ignoring pre-dependency problem!
Preparing to unpack .../archives/bash_4.4-5_m68k.deb ...
preinst: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dpkg: error processing archive /var/cache/apt/archives/bash_4.4-5_m68k.deb (--unpack):
 new bash package pre-installation script subprocess was killed by signal (Aborted)
Selecting previously unselected package bsdutils.
dpkg: regarding .../bsdutils_1%3a2.30.2-0.1_m68k.deb containing bsdutils, pre-dependency problem:
 bsdutils pre-depends on libsystemd0
  libsystemd0 is not installed.

qemu bug report is: https://bugs.launchpad.net/qemu/+bug/1673976

[erikly01]

I'm also getting the same error with qemu-user

dpkg: warning: ignoring pre-dependency problem!
Preparing to unpack .../archives/bash_4.4-5_arm64.deb ...
preinst: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dpkg: error processing archive /var/cache/apt/archives/bash_4.4-5_arm64.deb (--unpack):
 new bash package pre-installation script subprocess was killed by signal (Aborted)

[LocutusOfBorg]

same error message here http://paste.ubuntu.com/26140607/

[jstarks]

These errors are all expected pre-build 17046. If you see these errors on 17046 or newer, please let us know.

[Zenexer]

For those of you not on the Insider channel, I made a workaround script. If you want to update to Ubuntu 17.10, that should do the trick, but be warned it could have unintended side effects in scenarios I haven't tested, and could cause problems when you do eventually receive the fix from Microsoft.