Doug MacEachern wrote:
>
> On Tue, 6 Jun 2000, Tom Lancaster wrote:
>
> > Here's the output of gdb: ( now what does this mean?)
> ...
> > Breakpoint 1, 0x400ddd35 in exit () from /lib/libc.so.6
> > (gdb) bt
> > #0 0x400ddd35 in exit () from /lib/libc.so.6
> > #1 0x80851e1 in ap_start_restart ()
> > #2 0x8085454 in ap_start_restart ()
> > #3 0x80862d7 in ap_child_terminate ()
> > #4 0x8086a4d in main ()
> > #5 0x400d5a42 in __libc_start_main () from /lib/libc.so.6
> > (gdb)
>
> the exit() makes sense, since you have maxrequestsperchild set to 1, but
> the stacktrace should look more like this:
>
> (gdb) where
> #0 exit (status=0) at exit.c:40
> #1 0x80cf0eb in clean_child_exit (code=0) at http_main.c:493
> #2 0x80d1e83 in child_main (child_num_arg=0) at http_main.c:3893
> #3 0x80d23dc in make_child (s=0x821dbe4, slot=0, now=960572421)
> at http_main.c:4264
> #4 0x80d2537 in startup_children (number_to_start=5) at http_main.c:4346
> #5 0x80d2b54 in standalone_main (argc=6, argv=0xbffff624) at
> http_main.c:4634
> #6 0x80d32d3 in main (argc=6, argv=0xbffff624) at http_main.c:4961
>
> are you calling $r->child_terminate somewhere? that's not actually called
> anywhere in the apache source, it's just an api for modules.
I suspect that's being called somewhere in Embperl.
The hanging problem has gone away now, and it appears to have been due
to a rogue piece of shared memory - after I got rid of it with ipcrm sem
..., the children terminate properly, and the process table doesn't fill
up. Would that seem reasonable?
Tom
