Zombie processes

[Patrick Spinler]

Just another confirmation report.  I see this effect on a stock redhat 9 
box running an untainted redhat's 2.4.20-8 revision of the kernel with 
Codeweaver's recent version of crossover office.

$ uname -a
Linux lpea-dmt-rcmd.mayo.edu 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 
i686 i686 i386 GNU/Linux
$ /lib/libc.so.6
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
(snip)
$ cat /etc/redhat-release
Red Hat Linux release 9 (Shrike)
$ /opt/cxoffice/bin/wine --version
Wine 20040213
$ ps -Af | grep wine
pjs11     1857     1  0 May26 ?        00:00:26 [wine-pthread <defunct>]
pjs11     1986     1  0 May26 ?        00:00:54 [wine-pthread <defunct>]
pjs11    17105     1  0 Jun07 ?        00:00:43 [wine-pthread <defunct>]

I haven't raised a bug report anywhere because, well, the kernel guys 
would say 'it's redhat's kernel, talk to them', and the wine guys would 
say 'it's crossover's wine, talk to them'.

But, within these constraints, is there any way I could debug this ? I'd 
be happy to do some work to try to pin down where and how these procs 
are hanging, if someone could give me a few pointers in the right 
direction.  And even with the vendor kernel and wine, perhaps the 
knowedge might be useful.

Thanks,
-- Pat

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?
> 
>          Shachar
>