httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: seg fault in 2.0.23 :-(
Date Tue, 14 Aug 2001 05:39:56 GMT
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
>>>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.
>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
>we seg fault because the storage has been reused for something else. No thoughts on a
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,
        overlay_extension_mappings(p, add->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.


View raw message