Bill Stoddard wrote:
>>On Mon, Aug 13, 2001 at 08:26:12PM -0400, Bill Stoddard wrote:
>>
>>>I was just able to recreate this on my Windows machine. Will post an analysys (and
>>>
>perhaps
>
>>>a fix) later on.
>>>
>>I have a potential fix but no ability to recreate the fault. ;-)
>>Given the butt-ugly nature of the current code, I'll commit what I have and
>>you can take it from there.
>>
>>....Roy
>>
>
>Still broken after your commit.
>
>The problem is that we are creating an extension_info out of a subrequest pool and
>sticking it into a longer lived hash table (allocated out of the request pool I'm
>guessing). When we pull the extension_info out of the hash table later and try to use
>it,
>we seg fault because the storage has been reused for something else. No thoughts on a
>fix.
>
I think the problem might be in this block:
static void *merge_mime_dir_configs(apr_pool_t *p, void *basev, void *addv)
{
mime_dir_config *base = (mime_dir_config *) basev;
mime_dir_config *add = (mime_dir_config *) addv;
mime_dir_config *new = apr_palloc(p, sizeof(mime_dir_config));
int i;
attrib_info *suffix;
if (base->extension_mappings && add->extension_mappings) {
if (base->copy_mappings)
new->extension_mappings = base->extension_mappings;
else {
new->extension_mappings = apr_hash_make(p);
overlay_extension_mappings(p, base->extension_mappings,
new->extension_mappings);
}
overlay_extension_mappings(p, add->extension_mappings,
new->extension_mappings);
If base->copy_mappings is true upon entry into the function,
then the call to overlay_extension_mappings at the end will
use p to allocate data for insertion into base->extension_mappings.
If base->extension_mappings has been allocated from a pool with
a longer lifetime than p, then we'll eventually segv.
--Brian
