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
yet).
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/
make
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. */
(gdb)
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
one.
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
repository"
which you can use to find the diffs (I reverted the change immediately
afterwards).
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.
XXX
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,
-Karl
Received on Sat Oct 21 14:36:10 2006