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
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
On Tue, 8 Jun 2004, Robert Shearman wrote:
Shachar Shemesh wrote:
.... 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
I'm experiencing odd problems with RedHat 9, and it may or may not be related to Wine. Sometimes when I leave the computer for a while and come back, the screensaver has come on an the system has frozen. There is no response to the keyboard and mouse, and the system (apparently) doesn't respond to the network either. However, cycling the power and rebooting brings the ext2fs partions back up in a dirty state, requiring fsck. It could be a BIOS thing (sleep mode enabled), but it seems to only happen when I have Wine running.
Robert Shearman wrote:
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
Hey Rob,
The problem seems to be a kernel bug. It's been round since 2.6.0... in my experience it only seems to happen when you terminate a wine process using ^C or when the program crashes tries to start the debugger, fails, then you press ^C
Mike
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. ...
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
Same here, on a 2.6.5 vanilla kernel. Linux xxxx.xxxxx 2.6.5 #89 Sun Apr 4 20:13:40 EEST 2004 i686 unknown unknown GNU/Linux [sss]$ ps -f| grep wine user 20982 1 0 Jun09 pts/222 00:00:00 [wine-preloader] <defunct>
I had just run the cvs wine (up to date). Due to some other regression, I think I'll go back to April's tag.
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
Patrick Spinler wrote:
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'.
Actually, the kernel guys are more likely to say "it's a redhat kernel, does it also happen on vanilla kernel?". The answer is highly likely to be "no" (if I am guessing correctly, this problem has something to do with NPTL, which means it was only there in the 2.4 kernel to begin with because of a RedHat patch). However, as the problem DOES happen on vanilla 2.6 kernel, this will not be a problem to reconstruct.
Also, please bear in mind that in order to debug this you will positively absolutely have to compile your own kernel, from whatever sources.
But, within these constraints, is there any way I could debug this ?
It's a kernel bug. There is nothing a userspace program should be able to do in order to make such a problem appear. As such, you are asking this on the wrong list. Do try either lkml (linux kernel mailing list), or, more recommended, kernel-newbies.
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.
Like I said, debugging kernel problems is not within this list's knowledge base.
Shachar
-
David Lee Lambert -
Mike McCormack -
P. Christeas -
Patrick Spinler -
Robert Shearman -
Shachar Shemesh -
Shachar Shemesh