Bug#174521: libc6: threads on ppc leave zombies when they terminate
On Fri, Jan 31, 2003 at 12:42:25AM -0700, waoki wrote:
> On Tue, Jan 28, 2003 at 09:18:26PM -0700, waoki wrote:
> > On Sat, Dec 28, 2002 at 12:35:52AM -0500, Daniel Jacobowitz wrote:
>
> [snip]
>
> > > Not on my PPC. This seems more likely to be a bug in the benh kernel
> > > you're running; I've never seen it, on glibc 2.2.5 or 2.3.1 on PPC.
>
> [snip]
>
> > I'm therefore closing the bug I opened. (If I'm able to trigger it on a
> > kernel built from Debian-supplied sources, I'll reopen it and reassign
> > it to kernel.)
>
> It seems I spoke much too soon - posts to debian-powerpc in late
> September of 2002 claim that it occurs on 2.4.18 (non-benh, if I read
> it correctly).
And here is what I know so far (taken from an e-mail I'm composing to
debian-powerpc):
I've seen it happen on kernels 2.4.19-ben0 and 2.4.20-ben1. I've only
seen it on one machine, and these are the only two kernels I've tried on
that machine. I've not tried it with non-benh kernels, as I need things
that I don't think are in the standard tree yet.
The problem takes some time to manifest itself after boot. My laptop was
last rebooted in the morning of the 29th, and it took until the
afternoon of the 30th for the problem to start.
Once the problem has started, threaded programs leave zombies. I'm
usually running X by the time this happens. When I kill X, threaded
programs stop leaving zombies, and any daemons with zombie threads will
have their zombie threads go away the next time they spawn a thread.
When I start X again, programs start leaving zombies, unless I change my
.xsession from:
--- cut ---
xsetbg images/background/geese.im8.Z &
fvwm2
--- cut ---
to:
--- cut ---
fvwm2
--- cut ---
On a hunch, I changed my .xsession to say:
--- cut ---
sleep 5 &
fvwm2
--- cut ---
and programs left zombies again.
As a test, I then wrote this script:
--- cut ---
#!/bin/sh
sleep 1 &
sleep 10
--- cut ---
If I run the script while the system is not zombifying threads, the
system will start zombifying threads after the first (backgrounded)
'sleep' terminates, and will return to normal when the second 'sleep'
terminates. This applies to all threads on the system, including those
that are not children of the script and that belong to other users. This
occurs regardless of whether X is running.
This does not work to trigger the behavior on machines that haven't
already started exhibiting it - as far as I can tell, it only turns it
off and on once it's already happened.
I'll probably reassign this pending more data...
--
William Aoki waoki@umnh.utah.edu /"\ ASCII Ribbon Campaign
B1FB C169 C7A6 238B 280B <- key change \ / No HTML in mail or news!
99AF A093 29AE 0AE1 9734 prev. expired X
/ \
Reply to: