Ran command:
valgrind darcs optimize --reorder-patches --debug --timing >
optimize-reorder-segfault.txt 2>&1

With repository lazily based on: http://darcs.haskell.org/ghc-hashedrepo

Output is attached.

Attachments

• optimize-reorder-segfault.txt

To clarify, this happens even without valgrind. I had been vainly hoping that
valgrind might actually be able to trace the problem down.

Obviously, it doesn't have any knowledge of GHC's heap, so I'm not sure why I
was thinking it might help. (Perhaps I hadn't remembered that black holes are
heap objects?)

Oh, you might possibly want to use
http://naesten.dyndns.org:8080/repos/ghc-hashedrepo/ as a source, if d.h.o is
still crawling like it has been...

What version of GHC was your darcs compiled with?  Do you have a different
version of GHC to try, and if so, does the error go away?

What size is the darcs process when it dies?

I'm using the debian package ghc6 6.8.2-1.

Running under gdb to keep it from dying when it segfaults...
top says:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
                              
30512 naesten   23   5 34256  27m 3496 T  0.0  5.5   0:03.59 darcs

Just to be clear, was the darcs that showed this behavior compiled with
bytestring support enabled?

On 3/28/08, David Roundy <bugs@darcs.net> wrote:

> Just to be clear, was the darcs that showed this behavior compiled with
> bytestring support enabled?

I hadn't enabled it, so unless it was the default... no.

On Fri, Mar 28, 2008 at 09:41:09PM -0000, Samuel Bronson wrote:
> On 3/28/08, David Roundy <bugs@darcs.net> wrote:
> > Just to be clear, was the darcs that showed this behavior compiled with
> > bytestring support enabled?
> 
> I hadn't enabled it, so unless it was the default... no.

Hmmm.  For a while, it was the default.  Do you have the --exact-version
you compiled with?
-- 
David Roundy
Department of Physics
Oregon State University

On 3/28/08, David Roundy <bugs@darcs.net> wrote:
>
> On Fri, Mar 28, 2008 at 09:41:09PM -0000, Samuel Bronson wrote:
> > On 3/28/08, David Roundy <bugs@darcs.net> wrote:
> > > Just to be clear, was the darcs that showed this behavior compiled with
> > > bytestring support enabled?
> >
> > I hadn't enabled it, so unless it was the default... no.
>
> Hmmm.  For a while, it was the default.  Do you have the --exact-version
> you compiled with?

% darcs --exact-version
darcs compiled on Mar  9 2008, at 17:29:06
unknown

That's all I have. The tree was fairly up-to-date at the time...

On Fri, Mar 28, 2008 at 11:27:47PM -0000, Samuel Bronson wrote:
> On 3/28/08, David Roundy <bugs@darcs.net> wrote:
> >
> > On Fri, Mar 28, 2008 at 09:41:09PM -0000, Samuel Bronson wrote:
> > > On 3/28/08, David Roundy <bugs@darcs.net> wrote:
> > > > Just to be clear, was the darcs that showed this behavior compiled with
> > > > bytestring support enabled?
> > >
> > > I hadn't enabled it, so unless it was the default... no.
> >
> > Hmmm.  For a while, it was the default.  Do you have the --exact-version
> > you compiled with?
> 
> % darcs --exact-version
> darcs compiled on Mar  9 2008, at 17:29:06
> unknown
> 
> That's all I have. The tree was fairly up-to-date at the time...

Bytestring was disabled as a default option on March 4.  Between the
possibility that it wasn't immediately pushed, and that "fairly up-to-date"
included a few days of lag, my guess is that your darcs wasn't compiled
with that fix, and I think I'll close this bug for now.
-- 
David Roundy
Department of Physics
Oregon State University

Hmm, it does seem to be gone now.