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