After spending a number of hours on this, here is what I have learned:
. If you're going to test old code (e.g., checkout by date) to see if
it exhibits a certain bad behavior that you have now, make sure you
apply any patches after the magic date to fix known problems in
that level. Otherwise, you'll waste a lot of time :) It helps
to use an operating system where you can reliably get dumps, and
it helps if you actually look at the ones you get to make sure the
breakage is what you expect.
. "ulimit -n NNNN" is the way to bump up the file descriptor limit on
some systems where it is too low :)
. If you *don't* do "ulimit -n", current code (worker MPM on Solaris, at
least) will segfault like crazy. This was easy to hit with my
single-process worker configuration.
I'll put something in the STATUS file for this.
. Current code will segfault (worker MPM on AIX and Solaris, at least)
if you do apachectl graceful while banging on the server.
I'll put something in the STATUS file for this.
. Current code (worker MPM on Linux, at least) will segfault like
crazy if you turn on APR_POOL_DEBUG and add "-lefence " to the
beginning of EXTRA_LIBS in config_vars.mk (I guess this is the
right way to use ElectricFence).
I won't put anything in the STATUS file for this, though it is
likely a problem with our code somewhere. I was not successful in
looking at a dump or capturing a segfault in gdb.
Unfortunately, I went looking for a probable pool-related problem that
somebody told me about and I kept hitting this stuff :(
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
