httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c mod_include.c
Date Fri, 14 May 1999 15:36:20 GMT
On Thu, 13 May 1999, Raymond S Brand wrote:

> Dean Gaudet wrote:
> > 
> > ap_pool_join is an advisory debugging tool -- alloc.c does nothing to
> > ensure that you preserve the lifetimes appropriately.
> 
> I understand that. Please apply  the patch to mod_include and look at
> where the ap_make_sub_pool() I added is called.

Yeah I saw that:

	/* Kludge --- Doing this allows the caller to safely destroy the
	 * sub_req
	 */
	r->pool = ap_make_sub_pool(r->pool);

Sorry, but that's just way off my bogosity meter.

Consider this sequence:

    in module foo: my_p = ap_make_sub_pool(r->pool);
                   my_table = ap_make_table(my_p, 5);
    in your hacked mod_include: r->pool = ap_make_sub_pool(r->pool);
    in module foo: x = ap_pstrdup(r->pool, blahblahblah);
                   ap_table_setn(my_table, "abc", x);

That's broken.  And module foo isn't what's broken, it's doing something
that fits within the ancestor relationship... only the ancestry has been
broken.  Although I think the damage really only becomes apparent in
a cleanup.

Let's just say I'm going to take a lot more convincing that futzing with
r->pool is fine.  In general I consider that to be a read-only field.
You'd certainly screw up if we had contexts in the pool like we're
talking about for 2.0.

Dean


Mime
View raw message