On Thu, Apr 14, 2016 at 10:59:57AM -0400, Eric Chamberland wrote: > just cloned a repo and it checked-out wihtout any error (with git 2.2.0) but > got come corrupted files (because I got some sdd failures). > > Then, I get a git core dump when trying to "git status" into the repo which > have a "bad sector" on sdd drive (crypted partition). > > I tried with git 2.2.0 AND git version 2.8.1.185.gdc0db2c.dirty (just > modified the Makefile to remove STRIP part) > > In both cases, I have a Bus error (core dumped) Interesting. There was a known issue with reading corrupted pack .idx files, but it was fixed in v2.8.0. So this could be a new thing. SIGBUS is somewhat rare, though (usually just accessing unmapped memory should get us a SIGSEGV). What platform are you on? I seem to recall that hardware like ARM that cares about memory alignment is more likely to get a SIGBUS. > Program received signal SIGBUS, Bus error. > 0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0 > (gdb) bt > #0 0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0 > #1 0x3334d90d8c20f3f0 in ?? () > #2 0xe59b5a6cd844a601 in ?? () > #3 0xc587a53f67985ae7 in ?? () > #4 0x3ce81893e5541777 in ?? () > #5 0xdeb18349a4b042ea in ?? () > #6 0x8254de489067ec4b in ?? () > #7 0x6fbef2439704c81b in ?? () > #8 0xe0eee2bb385a96da in ?? () > #9 0x00007ffff6e19ab3 in ?? () > #10 0x00007fffffffc4d0 in ?? () > #11 0x000000000000001d in ?? () > #12 0x00007ffff7863f80 in SHA1_Update () from /lib64/libcrypto.so.1.0.0 > #13 0x00000000005102c0 in write_sha1_file_prepare > (buf=buf@entry=0x7ffff6c81000, len=1673936, type=<optimized out>, > sha1=sha1@entry=0x7fffffffc750 "\340_~", hdr=hdr@entry=0x7fffffffc570 "blob > 1673936", So I'd assume here that the problem is in accessing the memory in "buf". to actually compute the sha1. That is mmap'd data, but the process is fairly bland (mmap however many bytes stat() tells us the file has, and then compute the sha1). You mentioned a bad sector; could it be that the filesystem is corrupted, and the OS is giving us SIGBUS when trying to read unavailable bytes from an mmap'd file? That would explain the SIGBUS versus SIGSEGV. What happens if you "cat" the file in question: > #15 0x00000000005159f8 in index_mem (sha1=sha1@entry=0x7fffffffc750 > "\340_~", buf=buf@entry=0x7ffff6c81000, size=1673936, > type=type@entry=OBJ_BLOB, > path=path@entry=0x80a818 "Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon", > flags=flags@entry=0) at sha1_file.c:3305 Can it show all of the bytes? I guess from the "size" field it's too big to manually verify, but "cat >/dev/null" should be enough to see if we can read the whole thing. > Ii would have expected git to first gave me an error when checking out the > files!!! Here is the log: > > Checking out files: 99% (28645/28934) > Checking out files: 100% (28934/28934) > Checking out files: 100% (28934/28934), done. > Already on 'master' > Your branch is up-to-date with 'origin/master'. > On valide le dépôt TestValidation avec la référence: > 9b4a485202b2b52922377842c15bfd605d240667 > HEAD is now at 9b4a485 BUG: On spécifie bash comme shell... > > But at least 1 file is corrupted! > > I keep preciously this faulty repo to further investigation with someone who > can help dig into the coredump and correct it... So _if_ my guess is right that you have filesystem corruption, git may not even know about it. It wrote the file, and the OS said "OK, success", not knowing it had been partially corrupted. And if that guess is right, it also means there's no git bug to fix. SIGBUS is the natural way for the OS to tell the process that mmap'd data isn't available. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html