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