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

Re: svn commit: r12604 - in branches/locking/subversion: libsvn_ra_dav mod_dav_svn

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-01-06 02:31:48 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> Take a look at the implementation of ne_lock(), as well as its
> docstring.
> It turns out that it's *required* that nlock.owner be malloc'd,
> because ne_lock() calles NE_FREE() on that field!

I looked at ne_lock before writing the mail, it's approximately

ne_lock(struct ne_lock* lock)
  struct lock_ctx ctx;

  // do stuff using ctx and lock

  if (success)
    if (ctx.active.owner)
       free(lock->owner); // lock->owner must have been malloced
       lock->owner = ctx.active.owner; // lock->owner still to be freeed
       ctx.active.owner = NULL; // ctx.active.owner won't be freeed
  ne_lock_free(ctx.active) // free ctx.active.owner if required

As far as I can see you must free the lock->owner that's returned from
ne_lock, otherwise it leaks.

> I was getting
> double-free errors from libc until I made this change.

Probably because an apr pool was freeing the lock->owner freed by neon
in ne_lock. However the lock->owner returned by ne_lock is not free'd
at all, I think it leaks.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 6 02:34:43 2005

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.