repository corruptions; possible causes?

[Sabin Iacob]

John Arbash Meinel wrote:
> Well, a 'segfault' is a bit different than raising an exception and dying. 

I am aware of that; the MemoryException encountered before was going 
back to the C code too, though...
> I
> realize it may feel the same to you, but for us it is very different. For a
> normal installation of bzr (pre-pyrex at least) a segfault generally means that
> your OS/Hardware something is having a problem. In my personal experience, I
> only get segfaults with bzr when Mac OSX is going crazy. (And at that time
> other programs are randomly segfaulting, too, and I need to reboot).
>   

I ran a check on my dick partitions today and it did discover and fix a 
few (lots of) misplaced inodes, but on the root partition, not on my 
home one; I guess this could explain voodoo segfaults and general funny 
behaviour

> The only other real avenues for a segfault are a bad C/Pyrex extension. I know
> bzr-svn is using an svn wrapper which has had some issues in the past. (It at
> least had a memory leak in one of the fairly important functions).
>
> I can't say for sure about "missing revision and abort". It sounds like your
> Branch claimed to be at revision 10, but your repository only contained
> information up to revision 9. Without seeing the tracebacks/errors/etc it is
> hard to say much more than that. (Either way, though, I would expect you to be
> able to start at an earlier revision and branch off of it).
>
> It is also possible that you had physical disk corruption (we've encountered
> hardware that ended up putting string of 100+ NULLs right in the middle of a
> file. And we are quite good about only appending to those files)
>   

actually, XFS does this often if not unmounted properly, but it adds 
NULLs at the beginning of the file, not in the middle; that's precisely 
why I have a cron job doing sync regularly

>> * and finally, I had some changes to bzr-svn I had committed (tests
>> didn't run on my system unless some names were fully qualified), and
>> trying to merge this morning I got
>>
>> bzr: ERROR: Revisions have no common ancestor:
>> iacobs at m0n5t3r.info-20070727163435-gbf1rp10ri60a63l
>> jelmer at samba.org-20070727111824-wnyzsuwiowm12553
>>     
>
> So you did a branch from bzr-svn, did some changes and committed, and then you
> were trying to merge and it was failing. (Just to make sure I understand)
>   

that's correct

> As this is an open-source project, would you be willing to post your branches?
> I can say something weird is happening, I don't know what yet.
>   

http://dev.m0n5t3r.info/oss/bzr-svn.broken/
http://dev.m0n5t3r.info/oss/bzr-svn.broken.tar.bz2

>   
>> and trying to branch from it would say
>>
>> bzr: ERROR: Could not install revisions:
>> iacobs at m0n5t3r.info-20070727163435-gbf1rp10ri60a63l
>>     
>
> Most of the primary devs (at least myself included) run the latest tip of
> bzr.dev all the time. (I will bzr update multiple times per day). Our trunk
> should be extremely stable. (It is only updated after the PQM has run 7k unit
> tests on it).
> It has been that way for more than a year now, and I've never had a true data
> corruption like you are seeing. And we have only had a couple small regressions
> in a long time. (0.15 introduced a few working tree regressions, 0.12 had a
> rather small regression because of a missing 'import' that wasn't noticed if
> you had bzrtools installed, I don't remember many more)
>   

I didn't have problems with bzr.dev (apart from the "manually edit 
.bzr/branch/format" after upgrading to 0.15 :))

> I hate to say that it sounds like hardware issues, but it pretty much does. If
> you want to post the tarballs somewhere, or mail them to me, I'll be willing to
> give them a look.
>   

well, it's certainly a reminder that backups can be useful :), although 
this one is probably related to the software suspend cycles and the 
times the laptop "forgets" to wake up and needs a cold restart