[darcs-devel] darcs patch: touch the "unrecorded changes" patch in ... (and 3 more)

[Ian Lynagh]

On Mon, Jun 20, 2005 at 08:50:52AM -0400, David Roundy wrote:
> On Mon, Jun 20, 2005 at 08:27:20AM +0200, Juliusz Chroboczek wrote:
> > > The sigbus occurs both on amd64/linux and on i686/linux.  I don't think
> > > that it's that we've removed the file *after* mmapping it, but rather that
> > > we remove the file *before* mmapping it.  Which suggests that our mmap
> > > is doing something wrong, since it should give a sigbus even in this
> > > scenario.
> > 
> > AFAIK, this sort of thing happens if you truncate a file that is
> > currently mapped.

Aha, this sounds like it might be the problem. I also get a sigbus if I
just mmap 100 bytes of a 0 byte file and then try to read byte 5 of it.

> That's what I thought the problem was at first, but in darcs we try our
> hardest never to truncate files, and I couldn't find when we did so.

I don't suppose you can find out which file it is causing this, assuming
it is one?

I'm not familiar with valgrind, so there could be an easier way, but if
I do:

strace -o w valgrind ./e

then the output includes:

==32233== Process terminating with default action of signal 7 (SIGBUS)
==32233==  Non-existent physical address at address 0x1B909005
==32233==    at 0x804986F: (within /tmp/c/e)

which I can match up against the strace output in w (note case
difference when searching!):

open("foo", O_RDWR|O_LARGEFILE)         = 3
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP RT_31], NULL, 8) = 0
gettid()                                = 32233
read(1017, "T", 2)                      = 1
mmap2(0x1b909000, 100, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) = 0x1b909000

It might be worth seeing if you can find a smaller test case first
and/or processing the strace file to find out what blocks where mmapped
at the end.


Thanks
Ian