Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Mon, 12 May 2008 12:27:33 -0400

To be exact, and I just looked again at the wait(3) man page, a process
is a zombie when all of the threads of a process have exited but its
parent has not called wait to collect the child's status information.
Yes the kernel structures are still allocated but all open files and
memory have been closed and returned to the system.  Kill -9 won't make
a zombie go away because it isn't running anyway.  I hadn't run across
the multi threaded case before and it looks you can have zombie threads
within a process where at least one thread is still running.

For arcane reasons to me, wait "collects" the child's statistics, such
as run time, and that is why a dead process's kernel structures have to
be preserved until the parent calls wait().  The init process adopts a
process if the parent dies before the child and so having init as a
parent does not mean it is a zombie, most of the system processes are
that way.

Andrew's insight explains why there are unintended threads still alive.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Pearson, MR
(Matthew)
Sent: Monday, May 12, 2008 11:58 AM
To: Michael Abbott; [email protected]
Subject: RE: Creating Zombies with epicsThreadExitMain

When a parent is exited, all the kernel structures for that process are
deallocated, but this isn't done for the child. If the child is still
running when the parent exits, it goes into zombie state and keeps all
the kernel data structures open, hence the /proc entry and open file.

The clone() call in the strace output looks like the place where the
child is created... 
Maybe is doesn't have time to finish before exit() is called?

.... After reading Andrews mail:

I guess that explains it. But why aren't the zombie tasks cleared up by
init?

"ps axms" is useful, you can see the thread information.

Cheers,
Matthew

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Michael Abbott
> Sent: 12 May 2008 14:16
> To: [email protected]
> Subject: Re: Creating Zombies with epicsThreadExitMain
> 
> > To reproduce this, create an EPICS IOC with the following code:
> > 
> > 	int main()
> > 	{
> >	    printf("Running iocsh\n");
> > 	    iocsh("/dev/null");
> >	    printf("Calling epicsThreadExitMain\n");
> > 	    epicsThreadExitMain();
> > 	}
> 
> For what it's worth, here are the last few lines from running
> 
> 	strace bin/linux-x86/softIoc
> 
> on the offending process:
> 
> ...
> write(1, "Running iocsh\n", 14Running iocsh
> )         = 14
> open("/dev/null", O_RDONLY)             = 3
> fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), 
> ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfe9c790) 
> = -1 ENOTTY (Inappropriate ioctl for device) mmap2(NULL, 
> 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
> = 0xb7f60000
> read(3, "", 4096)                       = 0
> close(3)                                = 0
> munmap(0xb7f60000, 4096)                = 0
> rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 
> mmap2(NULL, 135168, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f1f000
> mprotect(0xb7f1f000, 4096, PROT_NONE)   = 0
> clone(child_stack=0xb7f3f4c4, 
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD
> |CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CL
> EARTID|CLONE_DETACHED, parent_tidptr=0xb7f3fbe8, 
> {entry_number:6, base_addr:0xb7f3fba0, limit:1048575, 
> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
> seg_not_present:0, useable:1}, child_tidptr=0xb7f3fbe8) = 
> 5730 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(1, 
> "Calling epicsThreadExitMain\n", 28Calling epicsThreadExitMain
> ) = 28
> futex(0x7f81a0, FUTEX_WAKE, 2147483647) = 0
> _exit(0)                                = ?
> 
> 
> Curious.  I would have expected the _exit(0) call to have 
> done everything that's necessary.  As far as I can tell from 
> the man page, _exit is pretty well guaranteed to terminate 
> the program.
> 
<DIV><FONT size="1" color="gray">This e-mail and any attachments may
contain confidential, copyright and or privileged material, and are for
the use of the intended addressee only. If you are not the intended
addressee or an authorised recipient of the addressee please notify us
of receipt by returning the e-mail and do not use, copy, retain,
distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual
and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any
attachments are free from viruses and we cannot accept liability for any
damage which you may sustain as a result of software viruses which may
be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in
England and Wales with its registered office at Diamond House, Harwell
Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
Kingdom
</FONT></DIV> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System