On Sat, 8 Dec 2018, Michael Schmitz wrote: > > Can you strace the whole procedure (i.e. starting with the call to > chroot) from the outside? With time stamps, for preference? >
I'd rather wait for the results of Adrian's git bisection before spending more time on this bug. > The strace you did show with dash does indicate that SIGCHLD was sent by > the child process / thread but even before that, the parent process got > -ECHILD. > > To me, this would indicate that wait4 uses the wrong task struct to > search for childs / threads to check. > > Might this have something to do with it? > > > /* > > * Why not generic sys_clone, you ask? m68k passes all arguments on stack. > > * And we need all registers saved, which means a bunch of stuff pushed > > * on top of pt_regs, which means that sys_clone() arguments would be > > * buried. We could, of course, copy them, but it's too costly for no > > * good reason - generic clone() would have to copy them *again* for > > * do_fork() anyway. So in this case it's actually better to pass pt_regs * > > * and extract arguments for do_fork() from there. Eventually we might > > * go for calling do_fork() directly from the wrapper, but only after we > > * are finished with do_fork() prototype conversion. > > */ > > asmlinkage int m68k_clone(struct pt_regs *regs) > > { > > /* regs will be equal to current_pt_regs() */ > > return do_fork(regs->d1, regs->d2, 0, > > (int __user *)regs->d3, (int __user *)regs->d4); > > } > > > > Other architectures seem to treat clone() different from fork()? > These are probably questions for Andreas. glibc internals are not my forte. -- > Cheers, > > Michael > >