Hello,
Interestingly, using the build on the Apache website and the installer
recently posted, the issue is not there. I believe it is an APR issue and it
was probably fixed in HTTPd 2.2.8. Previously I did note the call to calloc
which should have zeroed memory out, but it still gave non-zero memory.
Regards,
Joel
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel_at_red-bean.com]
> Sent: Thursday, 28 February, 2008 6:07 AM
> To: Joel Low
> Cc: Subversion Users' List
> Subject: Re: Locks return 'Bad Request'
>
> > "Joel Low" <joel_at_joelsplace.sg> writes:
> > > I refer to my previous emails on the mod_dav_svn lock code. I'm not
> sure
> > > what the status is, but over the course of the last few months (2
> or 3)
> > > people have been asking me for the patch. May I ask if anything is
> going to
> > > be done about this?
> >
> > I couldn't tell from this if you have a patch, or if you're asking
> for
> > one. Is it the former or the latter?
>
> Oops, sorry, I didn't read the whole thread at:
>
> http://readlist.com/lists/subversion.tigris.org/users/3/19687.html
>
> I see now that you did trace it down into source, thanks. But when I
> look at the place in mod_dav_svn/lock.c you refer to, it is setting
> dlock->next to NULL -- just not explicitly, instead we depend on the
> apr_pcalloc() call. Here's the function in question:
>
> /*
> ** Create a (direct) lock structure for the given resource. A
> locktoken
> ** will be created.
> **
> ** The lock provider may store private information into lock->info.
> */
> static dav_error *
> create_lock(dav_lockdb *lockdb, const dav_resource *resource,
> dav_lock **lock)
> {
> svn_error_t *serr;
> dav_locktoken *token = apr_pcalloc(resource->pool, sizeof(*token));
> dav_lock *dlock = apr_pcalloc(resource->pool, sizeof(*dlock));
>
> dlock->rectype = DAV_LOCKREC_DIRECT;
> dlock->is_locknull = resource->exists;
> dlock->scope = DAV_LOCKSCOPE_UNKNOWN;
> dlock->type = DAV_LOCKTYPE_UNKNOWN;
> dlock->depth = 0;
>
> serr = svn_fs_generate_lock_token(&(token->uuid_str),
> resource->info->repos->fs,
> resource->pool);
> if (serr)
> return dav_svn__convert_err(serr, HTTP_INTERNAL_SERVER_ERROR,
> "Failed to generate a lock token.",
> resource->pool);
> dlock->locktoken = token;
>
> /* allowing mod_dav to fill in dlock->timeout, owner, auth_user.
> */
> /* dlock->info and dlock->next are NULL by default. */
>
> *lock = dlock;
> return 0;
> }
>
> Note that apr_pcalloc() zeroes out all of the buffer it allocates. So
> anything in *dlock that we don't set will be zero; if the subfield's
> type is pointer, that means the pointer will be NULL.
>
> Thus, we are initializing dlock->next to NULL. The question is, is
> that changing to a garbage value somewhere between our initialization
> and the place in httpd-2.2.8/modules/dav/main/util_lock.c that you
> referred to in
>
> http://readlist.com/lists/subversion.tigris.org/users/4/21432.html
>
> where you examined "Data->next"? Note that in httpd-2.2.8, the
> strings "data->next" and "Data->next" do not even occur in that file.
> There are a few places where there's a foo->next that might be what
> you're talking about, but without a function name or some context, I
> can't be sure.
>
> Can you reproduce this problem with latest development Subversion and
> a recent httpd (2.2.8)?
>
> Thanks,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-28 14:38:21 CET