Messages in this thread | | | Subject | Re: process 'stuck' at exit. | From | Darren Hart <> | Date | Tue, 10 Dec 2013 13:06:23 -0800 |
| |
On Tue, 2013-12-10 at 15:49 -0500, Dave Jones wrote: > On Tue, Dec 10, 2013 at 09:35:59PM +0100, Oleg Nesterov wrote: > > Dave, I must have missed something, help. > > > > I am looking at the first message and I can't understand who stuck > > "at exit". > > > > The trace shows that the task with pid=10818 called sys_futex() ? > > > > Perhaps "exit" means the userspace paths? > > pid 1131 is wait()'ing for 10818 to exit > > pid 1130 is periodically sending SIGKILL to 10818 because it's gotten > tired of waiting. 10818 is ignoring these because it's stuck in a loop > somewhere in the kernel. > > I tried attaching to 10818 with gdb, and it just hangs. > (possibly because its weird stack situation [see 1st post]) > > by inspecting the shared mapping that all processes have (by gdb'ing 1130) > I can see that 10818 did all its full run without incident, and the > "exit child" flag in the fuzzer had been in set. > > The last 'random syscall' the fuzzer did was to sys_accept4, so the futex call > must come from somewhere in libc maybe ?
If that is the case, then Linus' requeue_pi path is highly unlikely as FUTEX_CMP_REQUEUE_PI is not used by glibc (yet). That gives me hope as that way there be dragons. Knowing exactly what syscall was made would be very useful, but I don't know if that information is even available anymore.
-- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
| |