You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/16 08:27:25 UTC

Still up and running.

I have been tailing the error log for the last three and a half hours.  We
have not had a single seg fault, and the last time I checked we were
running over 230 child processes with no slow-down on that machine.  I am
going to bed, but I don't believe we will have any problems when I wake
up in the morning.

Congrat's everybody.  :-)

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Re: Still up and running.

Posted by Greg Ames <gr...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> 
> I have been tailing the error log for the last three and a half hours.  We
> have not had a single seg fault, 

(grins sheepishly :-) well, I quietly moved a couple of core dumps from
/tmp into corefiles/ .  I think you noticed them later.  And yes it's
true that we didn't have any seg faults while 2.0 was running in
production.  But earlier yesterday, when I was playing with the build,
we got one that I didn't notice until last night:

(gdb) bt
#0  0x281a1acf in _fini () from /usr/local/apache2/modules/mod_status.so
#1  0x280a8889 in find_symdef () from /usr/libexec/ld-elf.so.1
#2  0x280a8e2e in dlclose () from /usr/libexec/ld-elf.so.1
#3  0x80927b1 in dso_cleanup (thedso=0x80e7ecc) at dso.c:74
#4  0x808875a in run_cleanups (c=0x812f134) at apr_pools.c:625
#5  0x8088857 in apr_clear_pool (a=0x80b400c) at apr_pools.c:729
#6  0x80888b3 in apr_pool_destroy (a=0x80b400c) at apr_pools.c:758
#7  0x8088843 in apr_clear_pool (a=0x80b100c) at apr_pools.c:724
#8  0x80888b3 in apr_pool_destroy (a=0x80b100c) at apr_pools.c:758
#9  0x80687ef in destroy_and_exit_process (process=0x80b107c,
    process_exit_value=0) at main.c:201
#10 0x8068f22 in main (argc=3, argv=0xbfbffb28) at main.c:430
#11 0x8058af5 in _start () 

I recall seeing duplicate cleanups back when I was working on dso on
OS/390.  One was in mod_so, and one was in APR I think.

I will dig into this more in a bit, but thought I would make the
backtraces from the two core dumps public first, in case anybody already
has the solution.

Greg