Re: erm.... 1.3 is messed up?

[Martin Kraemer <Ma...@mch.sni.de>]

Hi, I'm back again, buried under hundreds of new-httpd mails....

On Sun, Sep 28, 1997 at 02:28:58PM -0700, Dean Gaudet wrote:
> No I've never claimed to have fixed the corruption problem.  I'm still
> waiting for something that I can reproduce... or more data from Martin, I
> forget what I asked him for though. 
> 
> Dean

On Fri, 12 Sep 1997 16:12:43 -0700, Dean had written...

>> To: new-httpd@apache.org
>> Subject: Re: Huh? Windows oddness (long dbxtrace)
>>
>> I wonder if these are all related to the SEGVs that I started seeing when
>> I did a "cvs update" after I got back from burning man (tuesday sept 2).
>> Can you folks try doing a few 'cvs -D "a week ago"' checkouts and see
>> when it started happening?
>>
>> I think core_dir->opts is buried under a macro or function call.

I tried to look through the sources (and within the debugger) for clues
to nail down this bug. But neither checking source references to "->opts"
nor selectively tracing central routines (directory_walk etc) helped me
any further.

In the meantime, I have a suspicion, but not enough internal knowledge
to decide if it is sensible:
Is it possible that _after_ destroy_subpool(), there are still dangling
references to things which were stored in the subrequest? That would
explain why the crashes never occur at the same code location (depending
on the server's request history) and why it can be several different core
stuctures which are trashed by apparently new request info.

What do you guys think, could it be possible? If yes, then _very_many_
functions' pool arguments would have to be checked, right?! :-(

    Martin
-- 
| S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Re: erm.... 1.3 is messed up?

[Dean Gaudet <dg...@arctic.org>]

On Wed, 1 Oct 1997, Martin Kraemer wrote:

> In the meantime, I have a suspicion, but not enough internal knowledge
> to decide if it is sensible:
> Is it possible that _after_ destroy_subpool(), there are still dangling
> references to things which were stored in the subrequest? That would
> explain why the crashes never occur at the same code location (depending
> on the server's request history) and why it can be several different core
> stuctures which are trashed by apparently new request info.

This has been my suspicion for a while too -- either that or a module
calling get_module_config with the wrong struct module.  But since I got
that "Ouch!  Freeing already free block" error today I think it's less
likely to be a get_module_config problem.

> What do you guys think, could it be possible? If yes, then _very_many_
> functions' pool arguments would have to be checked, right?! :-(

Well given that I got the problem today with a very small set of modules I
think we can start by finding out just how small that set of modules needs
to be.  I had:

AddModule modules/standard/mod_env.o
# this is non-standard, but I don't suspect it
AddModule modules/hotwired/mod_log_hotwired.o
AddModule modules/standard/mod_mime.o
AddModule modules/standard/mod_negotiation.o
AddModule modules/standard/mod_status.o
AddModule modules/standard/mod_dir.o
AddModule modules/standard/mod_asis.o
AddModule modules/standard/mod_imap.o
AddModule modules/standard/mod_actions.o
AddModule modules/standard/mod_alias.o
AddModule modules/standard/mod_access.o
AddModule modules/standard/mod_auth.o
AddModule modules/standard/mod_expires.o
AddModule modules/standard/mod_headers.o
AddModule modules/standard/mod_setenvif.o

Dean