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

Question

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

JackieKu opened this issue 8 years ago · 59 comments

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

Edit the locale list at /etc/locale.gen.
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

Answer 1 · 2017-04-11T10:22:50.000Z

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.

Answer 2 · 2017-04-13T19:10:32.000Z

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

alwsl/alwsl#37

Answer 3 · 2017-04-13T19:53:09.000Z

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

Answer 4 · 2017-04-13T19:54:07.000Z

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!)

Answer 5 · 2017-04-13T20:18:59.000Z

Hopefully this helps... #1306 (comment)

Answer 6 · 2017-04-14T18:01:43.000Z

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.

Answer 7 · 2017-04-14T20:04:00.000Z

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;
}

Answer 8 · 2017-04-15T02:41:36.000Z

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?

Answer 9 · 2017-04-16T13:36:57.000Z

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

Answer 10 · 2017-04-23T02:12:32.000Z

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 tromey@redhat.com
and Alexandre Duret-Lutz adl@gnu.org.
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 bug-m4@gnu.org: Aborted
autom4te: m4 failed with exit status: 2
aclocal: error: echo failed with exit status: 2`

Is there any get around in this issue?

Answer 11 · 2017-04-23T02:44:47.000Z

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

Answer 12 · 2017-04-23T15:03:34.000Z

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.

Answer 13 · 2017-04-23T15:22:00.000Z

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.

Answer 14 · 2017-04-23T15:50:26.000Z

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.

Answer 15 · 2017-04-23T17:36:51.000Z

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.

Answer 16 · 2017-04-26T13:32:54.000Z

@Christoph-Wagner That exactly helps! THX dude.

Answer 17 · 2017-08-17T09:08:49.000Z

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.

Answer 18 · 2017-08-17T15:08:31.000Z

@bobvanderlinden I've followed this on ArchLinux https://wiki.archlinux.org/index.php/Install_on_WSL, it contains links for fixed packages, and it works, I just installed them. Not sure it's easy to port it to your plataform.

Answer 19 · 2017-08-18T02:15:38.000Z

I keep putting off doing a wsl-glibc PPA for Ubuntu with the cherry pick I mentioned in April. This blocks Yakkety/Ardvark as well as the rolling update distros like Arch&Gentoo. That said, Ubuntu 18 won't go LTS for a long time. It is a pain for people running static binaries like Yocto though, and there isn't much you can do there except rebuild against a working glibc.

Answer 20 · 2017-08-18T02:23:47.000Z

@therealkenc cherry picking or reverting just like the AUR wsl-glibc package does?

Answer 21 · 2017-08-18T02:27:06.000Z

@oblitum - Reverting. If you are motivated enough just apt-get source glibc and revert the change locally.

Answer 22 · 2017-08-18T02:31:46.000Z

@therealkenc I can't say for others but my motivation is enough to have my working Arch now rather than Ubuntu ;-)

Answer 23 · 2017-08-18T07:35:48.000Z

@oblitum It's harder to do in NixOS, since packages are build with reference to one exact copy of glibc. Changing glibc would usually result in all packages needing to be rebuild. In addition, patching each and every distro with a custom glibc package doesn't seem like a good solution. I'm wondering what is needed to get the right functionality in WSL and whether I can help in any way to do so?

Answer 24 · 2017-08-18T14:30:58.000Z

@bobvanderlinden The thing right now is that since there are workarounds, this isn't prioritized. It is definitely on their radar though

Answer 25 · 2017-08-18T15:23:16.000Z

Sorry for letting this thread go stagnant, and thanks to @therealkenc for digging in as always. Fully supporting all the flags of the clone system call is something that I'd like to address. I'll take a look at this, but full disclosure since we're nearing lockdown for Fall Creator's Update, the change is unlikely to make that release, but I'll see what I can do.

Answer 26 · 2017-08-18T19:15:11.000Z

@therealkenc I can't say for others but my motivation is enough to have my working Arch now rather than Ubuntu ;-)

Sad, I've just discovered that systemd/systemctl doesn't work on WSL. This is a show stopper...

Answer 27 · 2017-08-18T20:42:11.000Z

@oblitum - You can vote for that here.

Answer 28 · 2017-09-13T02:56:52.000Z

This bug is annoying, i have to recompile glibc every time i upgrade it. It wastes me a lot of time.

Answer 29 · 2017-09-15T04:36:09.000Z

@tuxzz You can make a backup of /usr/lib/locale/locale-archive, when glibc upgrades, restore it.

Answer 30 · 2017-09-15T10:27:59.000Z

@goreliu Not only locale-gen but also clang and many other programs crash due to this bug.

Answer 31 · 2017-10-13T20:54:47.000Z

I've been working hard at fixing this. Supporting CLONE_VM correctly has required some significant refactoring. Please hold on a little longer.

Answer 32 · 2017-10-20T18:13:11.000Z

Extra tidbits, it also affects me after upgrading to Ubuntu 17.10 when doing the first apt upgrade.
With following error:

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):

Answer 33 · 2017-10-21T14:06:35.000Z

@ardhitama here too. "solved" it temporarily by holding offending packages before do-release-upgrade:

sudo apt-mark hold bash
sudo apt-mark hold ebtables

Answer 34 · 2017-10-30T12:44:03.000Z

@heldchen The apt-mark trick unfortunately doesn't work here. I recommend WSL users to stick on zesty for now.
Also, can anyone confirm if this is fixed on 17025?

EDIT: I'm on 17025, boom. Better sit back and wait for a few more releases :(

Answer 35 · 2017-10-30T12:47:13.000Z

@TerrorJack it worked fine for me, and so does 17.10 :)

me@devbox:~$ uname -a
Linux devbox 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
me@devbox:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 17.10
Release:        17.10
Codename:       artful
me@devbox:~$

Answer 36 · 2017-10-30T15:27:02.000Z

Curious: What does ldd --version return after you upgrade to 17.10 artful if you pin bash.

Answer 37 · 2017-10-30T15:47:50.000Z

me@devbox:~$ ldd --version
ldd (Ubuntu GLIBC 2.26-0ubuntu2) 2.26
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Answer 38 · 2017-10-30T16:36:07.000Z

Thanks, appreciated. [My insider upgrade took down all of Windows with a green screen loop at boot so couldn't check myself until I deal with that.]

Since you've got 2.26, I suspect you'll find fish, m4, clang, and all the rest cited in this thread above (plus whatever undiscovered gems) will still fail. You could hold them all of course, assuming you knew everything that is going to take the glibc CLONE_VM dependency. But that's sort of where we started.

Answer 39 · 2017-10-30T18:19:09.000Z

Good news -- we've got this fixed in an internal build now, and I'm successfully running Ubuntu 17.10 on my machine.

Sorry this didn't make 17025 -- I'll post an update once this makes it into an insider build.

Answer 40 · 2017-10-30T18:22:28.000Z

@jstarks, so, release users should stick on 17.04?

Answer 41 · 2017-10-30T18:45:11.000Z

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

Answer 42 · 2017-10-30T20:20:58.000Z

Since you've got 2.26, I suspect you'll find fish, m4, clang, and all the rest cited in this thread above (plus whatever undiscovered gems) will still fail.

absolutely. holding bash only fixes the do-release-upgrade erroring out on zesty → artful.

glad to see a fix is inbound tho.

Answer 43 · 2017-10-31T14:58:43.000Z

@matshch Stick with 16.04 LTS for now.

Answer 44 · 2017-10-31T15:57:32.000Z

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

Answer 45 · 2017-11-01T02:19:01.000Z

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

Answer 46 · 2017-11-02T00:42:22.000Z

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

Answer 47 · 2017-11-08T21:10:38.000Z

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

Answer 48 · 2017-11-08T21:14:21.000Z

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.

Answer 49 · 2017-11-16T21:56:00.000Z

Was this fixed in 17040 ?

Answer 50 · 2017-11-16T23:06:56.000Z

@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:~$

Answer 51 · 2017-11-22T18:52:46.000Z

Windows Insider Build 17046 has improved CLONE_VFORK and CLONE_VM support.

Answer 52 · 2017-11-22T18:54:19.000Z

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

Answer 53 · 2017-11-22T19:19:27.000Z

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

Answer 54 · 2017-11-22T19:39:11.000Z

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.

Answer 55 · 2017-11-26T20:30:34.000Z

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

Answer 56 · 2017-11-29T21:21:16.000Z

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)

Answer 57 · 2017-12-08T17:29:22.000Z

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

Answer 58 · 2017-12-08T17:41:03.000Z

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

Answer 59 · 2018-02-07T23:48:55.000Z

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.