Re: [Monotone-devel] segmentation fault in changesetify

[Nathaniel Smith]

On Sun, Apr 03, 2005 at 09:16:29PM +0200, Martin Kihlgren wrote:
> - I have put the original (0.14) database at
>   http://troja.ath.cx/~zond/files/monotone.db-pre-change
> - I have put the new (the one I have dumped, loaded etc - that the "db
>   changesetify" failed on) database at
>   http://troja.ath.cx/~zond/files/monotone.db

Ah-hah, this helps (and the backtrace confirms it) -- the problem is
that you have a loop in your ancestry.  (This was possible back in
0.14, and one of the reasons changesets were created...)  The rebuild
code traverses the graph it's rebuilding recursively, and we forgot to
put in a cycle-detector.  So... it ends up trying to find the end up
the loop, goes around a few thousand times, and eventually runs out of
stack space.  Oops.

It's not possible to express something like this in modern monotone,
which is normally good ;-), but in your case it's a little bit bad,
because it means that there's no way to directly translate your
history.

The exact problem is that you have two loops:
   6d4e39 -> be6472 -> 5954cc -> be6472
   f026d7 -> 6dcfe8 -> b7ba8f -> 6dcfe8
             ^^^^^^              ^^^^^^  <-- these are the same   
                       ^^^^^^ <-- this is the problematic node

I would guess that what happened is that you made some change, and
then decided it was a bad idea after all and reverted it, returning
you to the previous tree state.

So... we have to untangle this somehow.  There are a few choices:
  - kill the problematic manifest entirely.  This removes it (and it
    alone) from your history, which is generally considered a bad
    thing, but perhaps you don't care in this case.  This requires
    some playing around with the database, so as not to break the
    delta encoding stuff, but I can do it.
  - kill one of the edges.  this would leave you with a somewhat odd
    looking revision graph, like:
           A          A
           |          |
           B  C   or  B
           | /        |
           D          D
           |          | \ 
           E          E  C
    depending on which edge we kill.  Either should work fine, though
    in the latter case you'd have a little merging to do, and you
    could still see every historical version (albeit in a strange
    setup).  This is extremely easy to do; it would only require
    removing one cert from the database.
  - actually unravel things the way they would be if you'd been using
    revisions all along.  This is the most correct thing to do, but
    also the trickiest; the easiest way is probably to write some
    special one-use-only code to revision.cc that would look at the
    graph it had constructed, check for the (hardcoded) manifest ids
    mentioned above, and tweak the graph appropriate in a hardcoded
    way.  Not too hard if you only need it to work once :-).  But
    tricky to check what your thoughts were before going ahead and
    doing it.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."