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

Milestone 1 status

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-10-08 01:25:27 CEST

As you may remember, today is Milestone 1 day. :-)

Milestone 1 is supposed to be:
   - checkout of a fresh tree (from/to xml files)
   - updates (same)
   - add files
   - commits of local mods (same)
   - commits of file adds (same)

We do not have all of these things working. We have this:
   - checkout of a fresh tree
   - updates
   - add files
   - delete files
   - oooh, commits are so close I can taste it, but not there yet, sigh. :-(

modulo properties (I think the fs handles props right, but wc does not

Unfortunately -- confession time -- a nasty allocation bug of some
sort, which I had encountered once before, is insistently manifesting
itself. It's reproducible now, and a very high priority, as I do not
think we can complete the milestone until it's nailed. It has taken
quite a bit of my time over the last couple of days, and will be all I
work on starting when I get back from a short trip out-of-town this
coming Friday. Unless someone has fixed it by then, of course.

I wish I could give more debugging information than the brief
reproduction recipes below, but anyway it's what I have so far.
[Highly lame of me to be posting a description of a bug instead of
fixing the bug :-), however, I will be offline for several days
starting now, and people should know that this bug is lurking.]

In the meantime, I've tagged the tree as "milestone-1-beta". When
this bug is finally traced down, and commits are implemented, that
will be the real milestone 1; let's aim for Oct. 20th.

Below is all about the bug, search for "XXX" to skip this part:

rm -rf libsvn_wc/tests/this # remove any test working copy
                               # that might be leftover from
                               # "make check"
cd libsvn_wc/
cd tests
gdb checkout-test
  (gdb) break free_dir_baton
  Breakpoint 1 at 0x8049826: file get_editor.c, line 178.
  (gdb) ignore 1 2
  Will ignore next 2 crossings of breakpoint 1.
  (gdb) run checkout-1.delta this
  Starting program: .../checkout-test checkout-1.delta this
  Linux thread target has modified Unknown signal handling
  Breakpoint 1, free_dir_baton (dir_baton=0x80a884c) at get_editor.c:178
  (gdb) n
  (gdb) p dir_baton->path->data
  $1 = 0x80c6504 "this/A/B"
  (gdb) n /* Okay, as soon as you've stepped over
                                  the call to svn_wc__entry_merge(),
                                  examine this/A/B/SVN/entries, and
                                  you'll see some data corruption. */

The bug has also manifested itself (more often) as corruption inside
svn strings, but I am not able to reproduce that reliably yet.

Greg Hudson recently checked in some major changes to the
xml-tag-writing library; however, given that this bug has happened
before, and Greg's changes seem to be working fine most of the time, I
highly doubt that he introduced a bug... Rather, stimulated an old

Another, possibly more helpful, reproduction recipe is to check out
the source tree as of 2000-10-07 05:28 UTC, build it, go into
libsvn_wc, and run make check. That gets a reliable seg fault, but
this time it corrupts data inside a subversion data structure (an edit
baton) and may be easier to trace. When I stimulated this, I made a
log entry that included this text:

   "Changes to get the correct target dir behavior. But this stimulates
   the old alloc bug, which now becomes highest priority. :-) This
   change will be reverted in a moment, I just want to have it in the

which you can use to find the diffs (I reverted the change immediately

What do I suspect: I wonder if there isn't something wrong in
svn_pool_create(), or if I'm making a wrong assumption about pools.
My understanding:

   When you create a pool with apr_make_subpool() -- or with
   apr_pool_create() passing a non-null CONT arg -- the new pool is a
   child of the the parent pool. And that when you destroy or clear a
   parent pool, the memory of *all* its descendents is either free'd
   or available for reuse (respectively), but that the parent and all
   its descendents are sacred until then. And that freeing a sibling
   of POOL (or freeing some other related-but-not-a-direct-ancestor
   pool of POOL) should never affect POOL.

Pretty non-controversial, but a sanity check wouldn't hurt here.


Anyway, sorry that the milestone is delayed. I'm glad we tried for
it, because it accelerated the pace of development and forced a lot of
things to come together, but I wouldn't consider it achieved yet.

Obviously, other things besides the bug can be worked on, and I hope
we'll continue at the same pace.

See y'all late next week,
Received on Sat Oct 21 14:36:10 2006

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