Zombie processes

[Robert Shearman]

Shachar Shemesh wrote:
> Hi all,
>
> Mike M told me on IRC that this matter has come up before, but I have
> not been able to find it in the archives. It seems Wine has been
> generating lots of zombie processes when it's not 100% cleanly killed. I
> have also seen the system hold a socket created from a wine process in
> "ESTABLISHED" state, when no process is registered as the socket's owner.
>
> According to Alexandre according to Mike, this is a kernel bug. Well, it
> most certainly is. Theoretically, there is nothing a user space process
> can do to cause zombies to stay around after their parent has exit, or
> keep sockets open after their controlling process has quit. As wine is a
> user space only process, this must be a kernel bug. No way around it.
>
> However, it happened to me both on RedHat 9 with 2.4.something (NPTL
> back ported), with both RH9's original kernel, and their most up to date
> one. It also happened on Debian Sid's almost-vanilla kernel 2.6.6. It
> happened with LD_ASSUME_KERNEL=2.4.1 making wine choose the standard
> threading mode, as well as without, choosing nptl. The zombies are
> sometimes called wine-pthread/wine-kthread, and sometimes
> wine-preloader. In short, I think this is a long standing Linux kernel
> bug, and Linus helps those who help themselves. I will also not be
> surprised if it was triggered by a wine bug.
>
> So the question is this. Is there anyone on this list who knows how to
> submit this as a question to lkml? The only time I tried to do anything
> remotely like it, I was seriously ridiculed. I understand from friends
> that live there that this is not an exceptional thing, so I'm a bit
> hesitant to go back there. If no one else does, however, I will. It will
> require me to untaint my kernel, so someone please save me from the slow
> armagatron I get when I'm not running nvidia, and report this :-)
>
> Will someone take this task on himself?

I've experienced the same thing on a perfectly clean kernel (I think
2.6.5-mm1), but I assumed it was because we were messing around with
signals. If I can reproduce the problem I will report it, although Mike
McCormack seems to have had quite a bit of contact already with the kernel
folks ;)

Rob