Re: [Qemu-devel] /usr/bin/m4: internal error detected

[Andreas Schwab]

On Dez 01 2017, John Paul Adrian Glaubitz  wrote:

> This isn't a bug in m4 or anything architecture-specific, it's a regression
> that was introduced by an upstream change in glibc [1] and mainly affects
> qemu-user which we are using for m68k and sh4 [2].

It's a bug in qemu-linux-user, which ignores CLONE_VFORK, turning vfork
into fork.  This breaks the expected semantics of vfork (VM sharing and
blocking the child until exec).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Qemu-devel] /usr/bin/m4: internal error detected

[Florian Weimer]

On 12/01/2017 10:51 AM, John Paul Adrian Glaubitz wrote:

Hi Daniel!

On 12/01/2017 06:08 AM, Daniel Kahn Gillmor wrote:


Copying file po/Makefile.in.in
Copying file po/Makevars.template
qemu: Unsupported syscall: -1
m4: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec 
>= 0' failed.
/usr/bin/m4: internal error detected; please report this bug to 
: Aborted

---


This isn't a bug in m4 or anything architecture-specific, it's a regression
that was introduced by an upstream change in glibc [1] and mainly affects
qemu-user which we are using for m68k and sh4 [2].

While the change in glibc is most certainly correct (I don't have enough
background knowledge to comment on that), it broke qemu-user for everyone
and so far there is no possible fix in sight.

I am CC'ing this to libc-alpha in the hope that someone from glibc upstream
might give us a tip on how to resolve the issue. Not being able to use 
qemu-user

anymore is quite a deal breaker because lots of people use qemu-user for
debugging issues on foreign architectures which is now no longer possible.


Is this ?  If 
yes, it should be fixed in master and on the 2.25 and 2.26 branches. 
2.24 and earlier should not be affected.


Thanks,
Florian

Re: [Qemu-devel] /usr/bin/m4: internal error detected

[Florian Weimer]

On 12/01/2017 12:58 PM, John Paul Adrian Glaubitz wrote:

The fix is already in the packaging source of Debian's glibc [1] after
I reported the bug. But the updated package has not been uploaded
to the FTP servers yet. I'll ask Debian's glibc maintainers to push
it.


Okay.  Based on the other responses, all these changes do is paper over 
bugs in the execution environment (wrong semantics of CLONE_VFORK), so 
patching glibc really isn't the proper fix.


Thanks,
Florian

Re: [Qemu-devel] /usr/bin/m4: internal error detected

[John Paul Adrian Glaubitz]

Hi Florian!

On 12/01/2017 11:40 AM, Florian Weimer wrote:

Is this ?  If yes, it
should be fixed in master and on the 2.25 and 2.26 branches. 2.24 and earlier
should not be affected.


You're right, this is indeed fixed by your patch.

I tried your patch first a few days ago but I my test setup was flawed so I
was still testing against the unpatched version of Debian's glibc package.

I now managed to test the patched version and this one does indeed work

Unpatched:

Generating locales (this might take a while)...
  en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: 
Assertion `ec >= 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
 done
Generation complete.
*** update-locale: Error: invalid locale settings:  LANG=en_US.UTF-8
(sid-m68k-sbuild)root@nofan:/tmp#

Patched:

Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
(sid-m68k-sbuild)root@nofan:/tmp#

The fix is already in the packaging source of Debian's glibc [1] after
I reported the bug. But the updated package has not been uploaded
to the FTP servers yet. I'll ask Debian's glibc maintainers to push
it.

Adrian


[1] 
https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=0a94d5f3ce5785b07372a810f011c62679be910e


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Qemu-devel] /usr/bin/m4: internal error detected

[John Paul Adrian Glaubitz]

Hi Daniel!

On 12/01/2017 06:08 AM, Daniel Kahn Gillmor wrote:


Copying file po/Makefile.in.in
Copying file po/Makevars.template
qemu: Unsupported syscall: -1
m4: ../sysdeps/unix/sysv/linux/spawni.c:366: __spawnix: Assertion `ec >= 0' 
failed.
/usr/bin/m4: internal error detected; please report this bug to 
: Aborted
---


This isn't a bug in m4 or anything architecture-specific, it's a regression
that was introduced by an upstream change in glibc [1] and mainly affects
qemu-user which we are using for m68k and sh4 [2].

While the change in glibc is most certainly correct (I don't have enough
background knowledge to comment on that), it broke qemu-user for everyone
and so far there is no possible fix in sight.

I am CC'ing this to libc-alpha in the hope that someone from glibc upstream
might give us a tip on how to resolve the issue. Not being able to use qemu-user
anymore is quite a deal breaker because lots of people use qemu-user for
debugging issues on foreign architectures which is now no longer possible.

Thanks,
Adrian


[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158
[2] https://bugs.launchpad.net/qemu/+bug/1673976


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Qemu-devel] /usr/bin/m4: internal error detected

[John Paul Adrian Glaubitz]

On 12/01/2017 01:18 PM, Andreas Schwab wrote:

This isn't a bug in m4 or anything architecture-specific, it's a regression
that was introduced by an upstream change in glibc [1] and mainly affects
qemu-user which we are using for m68k and sh4 [2].


It's a bug in qemu-linux-user, which ignores CLONE_VFORK, turning vfork
into fork.  This breaks the expected semantics of vfork (VM sharing and
blocking the child until exec).


Yes, I wasn't really arguing that it's a bug in QEMU as Adhemerval had already
explained. The problem was just that apparently resolving the issue in
QEMU isn't trivial as Peter Maydell mentioned in [1].

That's why I was looking for a workaround. However, I have re-tested Florian's
patch and it works for me now, it didn't when I tested it for the first time.

So, we have a workaround for the time being until the bug is resolved in QEMU.

Adrian


[1] https://bugs.launchpad.net/qemu/+bug/1673976


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913