This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: /usr/bin/m4: internal error detected



On 01/12/2017 08:40, Florian Weimer wrote:
> 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 <bug-m4@gnu.org>: 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 <https://sourceware.org/bugzilla/show_bug.cgi?id=22273>?  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.

As I wrote in the qemu-devel mailist [1], current GLIBC won't trigger any 
assert anymore, however I am not sure if posix_spawn semantic will work
for all the expected scenarios in qemu user-mode.

Most likely any failure (sched_set{param,scheduler}, setsid, setpgid,
seteuid, any file action or execve itself) won't be advertise to main
process, since err is set 0 as default and the auxiliary process will
write to a expected shared memory to signalling an issue.  This is 
mostly likely to happen if either CLONE_VFORK (since err will
be access concurrently) or/and if CLONE_VM are not respected 

As I described in maillist, I am not very compelled to change internal
posix_spawn to use a pipe2 on Linux mainly because 

  1. it uses a slight less resources than the generic POSIX one 
     (check e83be730910c) and it works on Linux kernel as expected.

  2. I personally do not see it a good precedence because we can't
     really foretell what kind of kernel ABI or semantic the non default 
     emulation runtime will support or not, so we can't really plan to 
     set what will break or not. 

I still think relying on what a Linux kernel actually provides us is the 
right approach and I would expected qemu would need to better support 
CLONE_VM and CLONE_VFORK (WSL has improved its implementation for the 
flags it seems [2]) in user mode. 

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04729.html
[2] https://github.com/Microsoft/WSL/issues/1878


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]