on 17/08/2011 23:21 Andriy Gapon said the following:
It seems like everything starts with some kind of a race between terminating
processes in a jail and termination of the jail itself. This is where the
details are very thin so far. What we see is that a process (http) is in
exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT
flag is set and even past the place where p_limit is freed and reset to NULL.
At that place the thread calls prison_proc_free(), which calls prison_deref().
Then, we see that in prison_deref() the thread gets a page fault because of what
seems like a NULL pointer dereference. That's just the start of the problem and
its root cause.
Then, trap_pfault() gets invoked and, because addresses close to NULL look like
userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes
on to call vm_map_growstack. First thing that vm_map_growstack does is a call
to lim_cur(), but because p_limit is already NULL, that call results in a NULL
pointer dereference and a page fault. Goto the beginning of this paragraph.
So we get this recursion of sorts, which only ends when a stack is exhausted and
a CPU generates a double-fault.
BTW, does anyone has an idea why the thread in question would "disappear" from
the kgdb's point of view?
(kgdb) p cpuid_to_pcpu[2]->pc_curthread->td_tid
$3 = 102057
(kgdb) tid 102057
invalid tid
info threads also doesn't list the thread.
Is it because the panic happened while the thread was somewhere in exit1()?
is there an easy way to examine its stack in this case?
--
Andriy Gapon
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
