>Process bash (pid: 1292, threadinfo=caaa2000 task=cbb02560)
>Call Trace:
> [<c01232ec>] __unhash_process+0x10c/0x170
> [<c01233dc>] release_task+0x8c/0x200
> [<c01251cb>] wait_task_zombie+0x15b/0x1c0
> [<c0125681>] sys_wait4+0x241/0x290
> [<c011cb10>] default_wake_function+0x0/0x20
> [<c011cb10>] default_wake_function+0x0/0x20
> [<c0109477>] syscall_call+0x7/0xb
>
>Code: 89 01 89 48 04 f0 ff 4b 04 0f 94 c0 31 f6 84 c0 74 1f 8b 43
>
>
>
0: 89 01 mov %eax,(%ecx)
2: 89 48 04 mov %ecx,0x4(%eax)
list_del(&link->pid_chain):
link->pid_chain->next, prev == 0x6b6b6b6b
5: f0 ff 4b 04 lock decl 0x4(%ebx)
%ebx: link->pidptr == 0x6b6b6b6b
The whole link structure is filled with slab poison. The link structure is embedded in the task struct stucture.
You mentioned that the last detach_pid() within __unhash_process oopsed. That means the reference count of the task structure was off by one, and the
put_task_struct(pid->task)
within
detach_pid(p,PIDTYPE_PGID);
freed the task structure.
The process was bash - does your bash use anything fancy, or plain boring single threaded app?
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/