[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: mod_ssl broken

From: Sander Striker <striker_at_apache.org>
Date: 2001-09-10 10:24:00 CEST

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> From: "Ben Laurie" <ben@algroup.co.uk>
> 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

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.