Oh, I see that the content_of_blob(rid=1864) fails to uncompress it with
rc=-5 (MZ_BUF_ERROR).
Then, it does:
if( rc!=Z_OK ){
blob_reset(&temp);
return 1;
}
And the result of blob_uncompress is ignored in content_of_blob(). That
shouldn't be ignored, I guess.
So, it seems that somehow a compressed blob was corrupted (it's a blob
never modified since 2010 in the repository, btw). Dumping the blob from a
correct repository copy and from a wrong repository copy, they are
different.
Here is the complete diff of xxd dumps of the 14MB blobs. It seems that
only a few bits where changed. Crazy.
561659c561659
< 00891fa0: f91d a2a6 facb 46bb af1f 4705 213d bcf6 ......F...G.!=..
---
> 00891fa0: e91d a2a6 facb 46bb af1f 4705 213d bcf6 ......F...G.!=..
561665c561665
< 00892000: 160c dc30 18c0 9d16 ac2c ad5c 91ae e181 ...0.....,.\....
---
> 00892000: 160c dc30 18c0 9d16 ec2c ad5c 91ae e181 ...0.....,.\....
561736c561736
< 00892470: a510 020a d423 feae 347d 32eb 759f 9935 .....#..4}2.u..5
---
> 00892470: a510 020a d423 feae 3c7d 32eb 759f 9935 .....#..<}2.u..5
561962c561962
< 00893290: 0bc3 aefb 8beb 89df 0d8d 1156 1945 e397 ...........V.E..
---
> 00893290: 0bc3 aefb 8beb 89df 0d8d 1156 9945 e397 ...........V.E..
562071c562071
< 00893960: 6f76 0b60 8a24 d0de 4f79 4aa8 d48b 5043 ov.`.$..OyJ...PC
---
> 00893960: 6f76 0b60 8a24 d0de 4f79 4aa8 d58b 5043 ov.`.$..OyJ...PC
562293c562293
< 00894740: 9132 7845 66b4 0369 acbe c47a d9a1 01a1 .2xEf..i...z....
---
> 00894740: 9132 7845 46b4 0369 acbe c47a d9a1 01a1 .2xEF..i...z....
562301c562301
< 008947c0: 483b fa06 b581 f3c3 eaad a528 0181 bbe6 H;.........(....
---
> 008947c0: 483b fa06 b781 f3c3 eaad a528 0181 bbe6 H;.........(....
On Thu, Mar 10, 2016 at 10:25:32AM +0100, Lluís Batlle i Rossell wrote:
> To add some info on the database using fossil sqlite:
>
> sqlite> select rid,size,uuid from blob where rid=1864;
> 1864|36923728|1831419b070d1f09420314feb8971548c1f28a18
> sqlite> select length(content) from blob where rid=1864;
> 14328966
>
> Regards,
> Lluís.
>
>
> On Thu, Mar 10, 2016 at 10:11:06AM +0100, Lluís Batlle i Rossell wrote:
> > Hello,
> >
> > using normally a repository with fossil 1.33 for weeks, it seems that it
> > just broke. We can't use the repository anymore, and even "rebuild" fails,
> > also with fossil trunk.
> >
> > We noticed the problem when doing a commit:
> >
> > """"
> > It says ERROR: [projects/file.txt] is 36923728 bytes on disk but 14328966
> > in the repository
> >
> > NOTICE: Repository version of [projects/file.txt] stored in
> > [file-24e13532928c08c6]
> >
> > working checkout does not match what would have ended up in the repository:
> > 4e7e15d6a398903d00bccbdec6137d79 versus 4e5221153df5c4311d874b1a6cf4b991
> > """"
> >
> >
> >
> > Now, doing a rebuild, it fails at ~20%:
> >
> > """"
> > fossil: ./src/blob.c:206: blob_reset: Assertion
> > `(pBlob)->xRealloc==blobReallocMalloc ||
> > (pBlob)->xRealloc==blobReallocStatic' failed.
> > Aborted
> > """"
> >
> >
> >
> > With valgrind, it finds an overlapping memcpy() at ~2% of the rebuild:
> > With gdb on the valgrind failing point of current trunk, notice:
> >
> > """"
> > (gdb) bt
> > #0 blobReallocStatic (pBlob=0x7fffffff6250, newSize=14328967) at
> > ./src/blob.c:194
> > #1 0x000000000040b3ba in blob_resize (pBlob=0x7fffffff6250,
> > newSize=14328966) at ./src/blob.c:422
> > #2 0x000000000040b3f6 in blob_materialize (pBlob=0x7fffffff6250) at
> > ./src/blob.c:432
> > #3 0x00000000004598d0 in manifest_parse (pContent=0x7fffffff6250,
> > rid=1864, pErr=0x0)
> > at ./src/manifest.c:383
> > #4 0x000000000045d337 in manifest_crosslink (rid=1864,
> > pContent=0x7fffffff6250, flags=0)
> > at ./src/manifest.c:1811
> > (gdb) print *pBlob
> > $12 = {nUsed = 14328966, nAlloc = 14328966, iCursor = 0, blobFlags = 0,
> > aData = 0x1988a98 "\270\026\006\367\377\177", xRealloc = 0x40ab12
> > <blobReallocStatic>}
> > (gdb) print pNew
> > $13 = 0x1988a90 "\220 \225\001"
> > """"
> >
> >
> > As you see, the pointer returned by fossil_malloc(14328967) is 8 bytes
> > before
> > pBlob->aData. Notice that it is the same "nUsed = 14328966" length as that
> > of the file of the commit. That file, in fact, is a txt of 36923728 in
> > length, but suspiciously, 14328966 is the exact length of the result of
> > "fossil test-compress" it.
> >
> >
> > What may have happened? We don't know of any power outage in this computer
> > that
> > may have broken the fs. We have been using the repository normally the last
> > weeks, doing commits.
> >
> >
> > --
> > (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
> > PGP key D4831A8A - https://emailselfdefense.fsf.org/
> > _______________________________________________
> > fossil-dev mailing list
> > fossil-dev@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
>
> --
> (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
> PGP key D4831A8A - https://emailselfdefense.fsf.org/
> _______________________________________________
> fossil-dev mailing list
> fossil-dev@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
--
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key D4831A8A - https://emailselfdefense.fsf.org/
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
