gour@gaura-nitai ~/r/d/darcs.net> ./darcs --version
2.0.0 (2.0.0 (+ -1 patch))
gour@gaura-nitai ~/r/d/darcs.net> ./darcs unrecord --repodir ~/darcs/emacs-bug/
Fri May 16 12:53:13 CEST 2008  Gour <dev@atmarama.org>
  * remove backup-directory stuff
Shall I unrecord this patch? (1/177)  [ynWsfvpxdaqjk], or ? for help: y
Fri May 16 09:51:35 CEST 2008  dev@atmarama.org
  * put all backup files in backups directory
Shall I unrecord this patch? (2/177)  [ynWsfvpxdaqjk], or ? for help: y
Fri May 16 09:42:50 CEST 2008  dev@atmarama.org
  * DVC stuff
Shall I unrecord this patch? (3/177)  [ynWsfvpxdaqjk], or ? for help: y
Wed May 14 10:37:48 CEST 2008  dev@atmarama.org
  * resolved conflict in ercrc.el (channel names)
Shall I unrecord this patch? (4/177)  [ynWsfvpxdaqjk], or ? for help: n
Skipped unrecord of 1 patch.
Thu Apr 24 17:00:44 CEST 2008  dev@atmarama.org
  * keep mm-url-use-external variable
Shall I unrecord this patch? (6/177)  [ynWsfvpxdaqjk], or ? for help: n
Skipped unrecord of 2 patches.
Mon Apr 21 12:33:14 CEST 2008  dev@atmarama.org
  * new default font for emacs due to radeon video driver
Hi!

Attempt to unrecord few patches from my repo crashes darcs with:

Shall I unrecord this patch? (9/177)  [ynWsfvpxdaqjk], or ? for help: n
Mon Apr 21 09:57:51 CEST 2008  Gour <dev@atmarama.org>
  * extended 'mm-discouraged-alternatives' handling properly rss feeds
Shall I unrecord this patch? (10/177)  [ynWsfvpxdaqjk], or ? for help: n
darcs: src/Darcs/Patch/Real.lhs:43Irrefutable pattern failed for 8:21-67:
pattern Data.Maybe.Just a2_minus_p1n1

I'm attaching the repo...

Sincerely,
Gour

Attachments

• emacs-bug.tar.bz2

Confirmed with darcs 2.0.0 + 202.

A big thank-you for the reproducible test case.  I think critical or urgent
sounds fair.

Escalating.  David?

issue701 may be related

Note also that the actual answers you give don't actually seem to make a
difference.  You can keep answering 'n' and still make darcs crash

Attached is a reduced version of the repository (32 patches instead of 164)
which blows up if you issue the command:
  darcs unpull -p 'added mailfilter'
(you can just run ./KABOOM.sh, which does the same thing)

Note that I've also been able to reproduce blowing up by trying to pull a patch
from an empty repo

Attachments

• emacs-bug-lite.tar.bz2

I've gotten around to taking a look at this, and it's clear (from manual
inspection) that the emacs-bug-lite repository is corrupt, which means we need
more information to track down this bug--since I've no idea how the corrupt
repository was generated.  I'm taking a look at emacs-bug.tar.bz2 right now, but
expect that it will show the same corruption, in which case we'll have quite a
chore ahead, trying to figure out how the corruption was introduced.

Gour, would you be able (and willing) to try to reproduce the steps you took to
create this repository? In particular, I suspect it would be helpful to have the
separate unmerged repositories, plus a sequence to reproduce the current one
that shows the bug.  I understand this is quite hard to do, but it's something
that you'll probably find easier than we will, plus you might have the separate
repositories available as a starting point.

David

Okay, I've verified that the emacs-bug repository is also corrupt.  There is a
reference in a conflictor to a patch

    hunk ./emacs 263
    -(load "~/.emacs.d/newsticker.el")
    +;;(load "~/.emacs.d/newsticker.el")

which doesn't exist in the history prior to that conflict.  You can view this using

darcs changes -v 2>&1 | less

There is a patch matching this description *after* these changes, so it's
possible that the corruption got introduced when that patch was commuted beyond
them, or there might have been another patch that was obliterated, or that
exists in a different repository that wasn't pulled.  In any case, while this
repository is proof that there's a bug in darcs, it doesn't allow us to
reproduce that bug, so someone is going to need to do more work to track it
down!  :(

I've got very intermittent connectivity right now and not all that much time, so
I'd appreciate some help on this one.

David

>>>>> "David" == David Roundy <bugs@darcs.net> writes:

Hello David,

thanks a lot for inspecting the bug...

David> Gour, would you be able (and willing) to try to reproduce the
David> steps you took to create this repository? In particular, I
David> suspect it would be helpful to have the separate unmerged
David> repositories, plus a sequence to reproduce the current one that
David> shows the bug.  I understand this is quite hard to do, but it's
David> something that you'll probably find easier than we will, plus you
David> might have the separate repositories available as a starting
David> point.

In the attachment I am sending both repos - from the desktop and laptop
machines. I believe it is next to impossible find a sequence which led
to the bug - I'm tweaking my emacs configuration regularly and then push
them from one machine to the other...

So, after sending first tarball out, I had to change all my passwords
and continued to use both repos, so I did: darcs get --to-match on both
machines and I hope the attached repos will be useful to someone to
discern what went wrong.

Sincerely,
Gour

Attachments

• bug-desktop.tar.bz2
• bug-laptop.tar.bz2
• unnamed

>>>>> "David" == David Roundy <bugs@darcs.net> writes:

David> There is a patch matching this description *after* these changes,
David> so it's possible that the corruption got introduced when that
David> patch was commuted beyond them, or there might have been another
David> patch that was obliterated, or that exists in a different
David> repository that wasn't pulled.  In any case, while this
David> repository is proof that there's a bug in darcs, it doesn't allow
David> us to reproduce that bug, so someone is going to need to do more
David> work to track it down!  :(

There is no 3rd repo - only the two repos sharing patching amongst
themselves, i.e. desktop <---> laptop and I sent those in the attachment
to previos reply.

Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

In case this helps with forensics, here is a trimmed down version of bug-laptop
which triggers the failure.  It has 27 patches.

Attachments

• bug-laptop-lite.tar.gz

Attached is an even lighter version (12 patches, 2 conflictors) where this bug
is triggered.  

It's called broken-12

Hopefully this can be boiled down into a test case (and isn't just propagating
brokeness from elsewhere)

Attachments

• broken-12.tar.gz

I doubt I'll have time to track this down, but just reducing the size of the
corrupt repository won't help: what we need to do is to reproduce the bug that
corrupted it, not to create a smaller repository that is also corrupt.  For all
we know, this bug may already be fixed, as I did fix a bug in the
conflict-handling not too long ago.  (see the fix for issue817)  So until we can
reproduce the bug causing this corruption, I think this has to be marked as a
need-eg.

David

Hmm, yeah :-(

I was hoping that reducing it would help us to trace the error (what is the
minimal set of patches we need to manipulate in order to generate this mystery
hunk), but I guess it didn't really help.  I tried looking through the
bug-{desktop,laptop} for a hint, but no luck yet.

One possible tip: notice that the email addresses attached to the patches are
different.  It seems like the 'Gour <dev@atmarama.org>' address is for the
desktop and the 'dev@atmarama.org' is for the laptop.  Maybe this can help us
reconstruct the events that led up to this bad conflictor.

Is there any hope for darcs repair to fix something like this?  

In general, it might be nice for recovery, if there was something like a darcs
rebase that let us yank out a patch and put something else in its place, if you
know what I mean. [maybe I just got the idea of rebase wrong, but sort of a
super-duper unsafe amend-record that lets us change patches and shift
dependencies accordingly]

On Mon, Jun 02, 2008 at 10:17:33AM -0000, Eric Kow wrote:
> Hmm, yeah :-(
> 
> I was hoping that reducing it would help us to trace the error (what is the
> minimal set of patches we need to manipulate in order to generate this mystery
> hunk), but I guess it didn't really help.  I tried looking through the
> bug-{desktop,laptop} for a hint, but no luck yet.
> 
> One possible tip: notice that the email addresses attached to the patches are
> different.  It seems like the 'Gour <dev@atmarama.org>' address is for the
> desktop and the 'dev@atmarama.org' is for the laptop.  Maybe this can help us
> reconstruct the events that led up to this bad conflictor.
> 
> Is there any hope for darcs repair to fix something like this?  

No, I don't think so.  It's a non-local problem, meaning that for every
conflict, darcs would have to search the entire repository to ensure that
all the conflicting patches actually exist, and that would be extremely
expensive, and relevant only when there are bugs in Darcs.Patch.Real.

> In general, it might be nice for recovery, if there was something like a darcs
> rebase that let us yank out a patch and put something else in its place, if you
> know what I mean. [maybe I just got the idea of rebase wrong, but sort of a
> super-duper unsafe amend-record that lets us change patches and shift
> dependencies accordingly]

This can still be done by hand.  You just edit the patch file, insert the
hash of the new file in the inventory, and if it's not the main inventory
then you need to insert the hash of the new inventory into another
inventory, etc.  Tedious, but doable.
-- 
David Roundy
Department of Physics
Oregon State University

>> Is there any hope for darcs repair to fix something like this?
>
> No, I don't think so.  It's a non-local problem, meaning that for every
> conflict, darcs would have to search the entire repository to ensure that
> all the conflicting patches actually exist, and that would be extremely
> expensive, and relevant only when there are bugs in Darcs.Patch.Real.

Perhaps if we had a sort of darcs repair-just-this-one-patch command,
this sort of thing would be viable (but maybe not worth the
programmer-effort).

I keep thinking that it would be nice to have a twin program called
evildarcs (codarcs?) that did all those things you wouldn't want to do
with darcs in daily life.  Like the yanking out and modifying of
patches in clear violation of dependencies, doing all the tedious
inventory-hacking for you.

Another idea that is floating around in my head is to go ahead and
implement darcs group and ungroup (unatomize and atomize).  This sort
of thing would be useful for forensics as well, helping to 'simplify'
repositories.

Just brainstorming.  Trying to find the best way to help people out
when darcs goes wrong.  And maybe the solution could even become
useful for daily life.

Setting this to expire at the end of the year (i.e. hoping that whatever
produced this was a bug in older darcs and that we will not see it again)

It would still be good if we had a general recovery mechanism for when things go
badly wrong, though :-/

This bug was set to expire a few months ago due to lack of reproducibility. 
Sorry, Gour :-(

If we could find the conditions that led to the repo corruption in the first
place,that'd be great.