Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Tue, Oct 23, 2001 at 05:00:04PM -0400, Greg Ames wrote:
> > Feeling brave, I decided to build with the threaded MPM and try a log
> > replay. I got a bunch of seg faults very quickly, no dump, and got
> > seg-fault-but-no-dump log messages. ps makes it look like the main
> > thread bailed out before all its worker threads exited. The server then
> > became useless.
> >
> > I re-built with the worker MPM, and got very similar results.
>
> FWIW, I took a fresh CVS checkout and worker is restarting fine for
> me. Can anyone else reproduce this? I tried killing off processes
> (sending the child a SIGKILL directly), and worker spawned off a new
> process accordingly (yay!) - took about a second, but that's the
> idle server maint period, IIRC.
This is very easy to reproduce, but you need to generate a synchronous
signal like SIGSEGV/SIGILL/whatever on one of the workers. I use a
module to do that (send it special args). Putting "*(int *)-1 =
0xbaaaaaad;" in the code somewhere temporarily does the trick too.
When used with worker MPM on Linux to cause a worker thread to segfault:
many threads for that process are presumably left around; ps output
for lt-httpd shows a bunch of threads with ppid 1
connection to browser is left open since process didn't completely
go away taking open file descriptors with it
server seems to process requests okay (though my browser -- IE -- is
hung; maybe it keeps trying to use the same connection to the server)
there is a log entry for the segfault
Try it on a different platform or different linux-kernel+glibc
combination and maybe it will work differently.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
