httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <>
Subject RE: mod_ssl broken
Date Mon, 10 Sep 2001 08:24:00 GMT
> From: William A. Rowe, Jr. []
> From: "Ben Laurie" <>
> Sent: Sunday, September 09, 2001 3:50 PM
>> Sander Striker wrote:
>>> The problem is that basev == NULL, which causes 
>>> apr_array_append to barf.
>>> I'll be looking into this next week (or someone working on 
>>> mod_ssl will).
>> I've looked into this slightly, and the underlying problem is that
>> ap_merge_per_dir_configs finds a previous cached merge (for /?) and
>> tries to use it but the entry for mod_ssl is NULL. The URL, btw, is
>> /svn.
> This is very, very odd.  Would someone please post the svn 
> create/merge dir config
> code, just in case it's clobbering a sibling?  The last silly 
> guess, perhaps we have
> a subrequest where the prev->pool has been destroyed (sounds 
> unlikely to me.)

#define INHERIT_VALUE(parent, child, field) \
                ((child)->field ? (child)->field : (parent)->field)


static void *dav_svn_create_dir_config(apr_pool_t *p, char *dir)
    /* NOTE: dir==NULL creates the default per-dir config */

    return apr_pcalloc(p, sizeof(dav_svn_dir_conf));

static void *dav_svn_merge_dir_config(apr_pool_t *p,
                                      void *base, void *overrides)
    dav_svn_dir_conf *parent = base;
    dav_svn_dir_conf *child = overrides;
    dav_svn_dir_conf *newconf;

    newconf = apr_pcalloc(p, sizeof(*newconf));

    newconf->fs_path = INHERIT_VALUE(parent, child, fs_path);

    return newconf;

Looks ok to me...

> There are no conditional create/merge results in mod_ssl, 
> whatsoever.  Ergo, it should always be given a base and addv, and return
> a new conf.
>> I got stuck at that point, coz it really isn't at all clear where the
>> entry was expected to be set in the first place. BTW, all but the first
>> entry in the cached merge were also NULL. I don't have time before
>> bedtime to figure this out, I'm afraid.
> It sounds as if I've failed to build/record/retrieve the 
> cache->walked result properly.  I'll hack at this a bit tommorow.  Hint, 
> server/request.c:1085 is the start of this block, and we should have a
> stack of walk_walked_t structures for every merge performed, recorded in
> the (cache_walk_t*)cache->walked apr_array.
> Bill

View raw message