{"thread":{"id":"42025","subject":"git status core dump with bad sector!","startedAt":"2016-04-14T14:59:57Z","lastAt":"2016-05-04T20:37:25Z","messageCount":3,"participants":["Eric Chamberland","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"283448","messageId":"570FB06D.5060308@giref.ulaval.ca","threadId":"42025","inReplyTo":null,"subject":"git status core dump with bad sector!","fromName":"Eric Chamberland","fromEmail":"eric.chamberland@giref.ulaval.ca","sentAt":"2016-04-14T14:59:57Z","receivedAt":"2016-04-14T14:59:57Z","isPatch":false,"sender":{"key":"eric.chamberland@giref.ulaval.ca","avatar":null},"body":"Hi,\n\njust cloned a repo and it checked-out wihtout any error (with git 2.2.0) \nbut got come corrupted files (because I got some sdd failures).\n\nThen, I get a git core dump when trying to \"git status\" into the repo \nwhich have a \"bad sector\" on sdd drive (crypted partition).\n\nI tried with git 2.2.0 AND git version 2.8.1.185.gdc0db2c.dirty (just \nmodified the Makefile to remove STRIP part)\n\nIn both cases, I have a  Bus error (core dumped)\n\nTried to make it more verbose:\n\nGIT_TRACE=2 GIT_CURL_VERBOSE=2 GIT_TRACE_PERFORMANCE=2 \nGIT_TRACE_PACK_ACCESS=2 GIT_TRACE_PACKET=2 GIT_TRACE_PACKFILE=2 \nGIT_TRACE_SETUP=2 GIT_TRACE_SHALLOW=2 /opt/gitgit/bin/git status\n10:54:30.644999 trace.c:318             setup: git_dir: .git\n10:54:30.645094 trace.c:319             setup: git_common_dir: .git\n10:54:30.645102 trace.c:320             setup: worktree: \n/pmi/cmpbib/compilation_BIB_gcc-4.5.1_64bit/TestValidation_avec_erreur_disque_git_core_dump_dans_dev_Test.ExportationVTK_Avion\n10:54:30.645112 trace.c:321             setup: cwd: \n/pmi/cmpbib/compilation_BIB_gcc-4.5.1_64bit/TestValidation_avec_erreur_disque_git_core_dump_dans_dev_Test.ExportationVTK_Avion\n10:54:30.645151 trace.c:322             setup: prefix: \nRessources/dev/Test.ExportationVTK/\n10:54:30.645181 git.c:350               trace: built-in: git 'status'\nBus error (core dumped)\n\nstarted in gdb:\n\nProgram received signal SIGBUS, Bus error.\n0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n(gdb) bt\n#0  0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n#1  0x3334d90d8c20f3f0 in ?? ()\n#2  0xe59b5a6cd844a601 in ?? ()\n#3  0xc587a53f67985ae7 in ?? ()\n#4  0x3ce81893e5541777 in ?? ()\n#5  0xdeb18349a4b042ea in ?? ()\n#6  0x8254de489067ec4b in ?? ()\n#7  0x6fbef2439704c81b in ?? ()\n#8  0xe0eee2bb385a96da in ?? ()\n#9  0x00007ffff6e19ab3 in ?? ()\n#10 0x00007fffffffc4d0 in ?? ()\n#11 0x000000000000001d in ?? ()\n#12 0x00007ffff7863f80 in SHA1_Update () from /lib64/libcrypto.so.1.0.0\n#13 0x00000000005102c0 in write_sha1_file_prepare \n(buf=buf@entry=0x7ffff6c81000, len=1673936, type=<optimized out>, \nsha1=sha1@entry=0x7fffffffc750 \"\\340_~\", hdr=hdr@entry=0x7fffffffc570 \n\"blob 1673936\",\n     hdrlen=hdrlen@entry=0x7fffffffc56c) at sha1_file.c:2951\n#14 0x000000000051567b in hash_sha1_file (buf=buf@entry=0x7ffff6c81000, \nlen=<optimized out>, type=<optimized out>, \nsha1=sha1@entry=0x7fffffffc750 \"\\340_~\") at sha1_file.c:3010\n#15 0x00000000005159f8 in index_mem (sha1=sha1@entry=0x7fffffffc750 \n\"\\340_~\", buf=buf@entry=0x7ffff6c81000, size=1673936, \ntype=type@entry=OBJ_BLOB,\n     path=path@entry=0x80a818 \n\"Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon\", \nflags=flags@entry=0) at sha1_file.c:3305\n#16 0x00000000005160ee in index_core (flags=0, path=0x80a818 \n\"Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon\", \ntype=OBJ_BLOB, size=<optimized out>, fd=7,\n     sha1=0x7fffffffc750 \"\\340_~\") at sha1_file.c:3367\n#17 index_fd (sha1=sha1@entry=0x7fffffffc750 \"\\340_~\", fd=7, \nst=st@entry=0x7fffffffc7c0, type=type@entry=OBJ_BLOB,\n     path=path@entry=0x80a818 \n\"Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon\", \nflags=flags@entry=0) at sha1_file.c:3410\n#18 0x00000000004eac66 in ce_compare_data (st=0x7fffffffc7c0, \nce=0x80a7c0) at read-cache.c:166\n#19 ce_modified_check_fs (ce=0x80a7c0, st=0x7fffffffc7c0) at \nread-cache.c:215\n#20 0x00000000004ebb6d in ie_modified (istate=istate@entry=0x7e5fe0 \n<the_index>, ce=ce@entry=0x80a7c0, st=st@entry=0x7fffffffc7c0, \noptions=options@entry=16) at read-cache.c:395\n#21 0x00000000004ebcfe in refresh_cache_ent \n(istate=istate@entry=0x7e5fe0 <the_index>, ce=ce@entry=0x80a7c0, \noptions=options@entry=16, err=err@entry=0x7fffffffc908,\n     changed_ret=changed_ret@entry=0x7fffffffc90c) at read-cache.c:1130\n#22 0x00000000004ed59c in refresh_index (istate=0x7e5fe0 <the_index>, \nflags=flags@entry=6, pathspec=pathspec@entry=0x7bb738 <s.25876+24>, \nseen=seen@entry=0x0, header_msg=header_msg@entry=0x0)\n     at read-cache.c:1221\n#23 0x0000000000429e3b in cmd_status (argc=<optimized out>, \nargv=0x7fffffffcca0, prefix=0x7e950f \n\"Ressources/dev/Test.ExportationVTK/\") at builtin/commit.c:1376\n#24 0x00000000004063b3 in run_builtin (argv=0x7fffffffcca0, argc=1, \np=0x7b4030 <commands+2352>) at git.c:352\n#25 handle_builtin (argc=1, argv=0x7fffffffcca0) at git.c:539\n#26 0x00000000004054a1 in run_argv (argv=0x7fffffffca80, \nargcp=0x7fffffffca6c) at git.c:593\n#27 main (argc=1, av=<optimized out>) at git.c:698\n\nIi would have expected git to first gave me an error when checking out \nthe files!!! Here is the log:\n\nChecking out files:  99% (28645/28934)\nChecking out files: 100% (28934/28934)\nChecking out files: 100% (28934/28934), done.\nAlready on 'master'\nYour branch is up-to-date with 'origin/master'.\n     On valide le dépôt TestValidation avec la référence: \n9b4a485202b2b52922377842c15bfd605d240667\nHEAD is now at 9b4a485 BUG: On spécifie bash comme shell...\n\nBut at least 1 file is corrupted!\n\nI keep preciously this faulty repo to further investigation with someone \nwho can help dig into the coredump and correct it...\n\nI am available to recompile a new git to help...\n\nThanks,\n\nEric\n"},{"id":"284090","messageId":"20160422051111.GA32107@sigill.intra.peff.net","threadId":"42025","inReplyTo":"570FB06D.5060308@giref.ulaval.ca","subject":"Re: git status core dump with bad sector!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-04-22T05:11:12Z","receivedAt":"2016-04-22T05:11:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 14, 2016 at 10:59:57AM -0400, Eric Chamberland wrote:\n\n> just cloned a repo and it checked-out wihtout any error (with git 2.2.0) but\n> got come corrupted files (because I got some sdd failures).\n> \n> Then, I get a git core dump when trying to \"git status\" into the repo which\n> have a \"bad sector\" on sdd drive (crypted partition).\n> \n> I tried with git 2.2.0 AND git version 2.8.1.185.gdc0db2c.dirty (just\n> modified the Makefile to remove STRIP part)\n> \n> In both cases, I have a  Bus error (core dumped)\n\nInteresting. There was a known issue with reading corrupted pack .idx\nfiles, but it was fixed in v2.8.0. So this could be a new thing.\n\nSIGBUS is somewhat rare, though (usually just accessing unmapped memory\nshould get us a SIGSEGV). What platform are you on? I seem to recall\nthat hardware like ARM that cares about memory alignment is more likely\nto get a SIGBUS.\n\n> Program received signal SIGBUS, Bus error.\n> 0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n> (gdb) bt\n> #0  0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n> #1  0x3334d90d8c20f3f0 in ?? ()\n> #2  0xe59b5a6cd844a601 in ?? ()\n> #3  0xc587a53f67985ae7 in ?? ()\n> #4  0x3ce81893e5541777 in ?? ()\n> #5  0xdeb18349a4b042ea in ?? ()\n> #6  0x8254de489067ec4b in ?? ()\n> #7  0x6fbef2439704c81b in ?? ()\n> #8  0xe0eee2bb385a96da in ?? ()\n> #9  0x00007ffff6e19ab3 in ?? ()\n> #10 0x00007fffffffc4d0 in ?? ()\n> #11 0x000000000000001d in ?? ()\n> #12 0x00007ffff7863f80 in SHA1_Update () from /lib64/libcrypto.so.1.0.0\n> #13 0x00000000005102c0 in write_sha1_file_prepare\n> (buf=buf@entry=0x7ffff6c81000, len=1673936, type=<optimized out>,\n> sha1=sha1@entry=0x7fffffffc750 \"\\340_~\", hdr=hdr@entry=0x7fffffffc570 \"blob\n> 1673936\",\n\nSo I'd assume here that the problem is in accessing the memory in \"buf\".\nto actually compute the sha1. That is mmap'd data, but the process is\nfairly bland (mmap however many bytes stat() tells us the file has, and\nthen compute the sha1). You mentioned a bad sector; could it be that the\nfilesystem is corrupted, and the OS is giving us SIGBUS when trying to\nread unavailable bytes from an mmap'd file?\n\nThat would explain the SIGBUS versus SIGSEGV.\n\nWhat happens if you \"cat\" the file in question:\n\n> #15 0x00000000005159f8 in index_mem (sha1=sha1@entry=0x7fffffffc750\n> \"\\340_~\", buf=buf@entry=0x7ffff6c81000, size=1673936,\n> type=type@entry=OBJ_BLOB,\n>     path=path@entry=0x80a818 \"Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon\",\n> flags=flags@entry=0) at sha1_file.c:3305\n\nCan it show all of the bytes? I guess from the \"size\" field it's too big\nto manually verify, but \"cat >/dev/null\" should be enough to see if we\ncan read the whole thing.\n\n> Ii would have expected git to first gave me an error when checking out the\n> files!!! Here is the log:\n> \n> Checking out files:  99% (28645/28934)\n> Checking out files: 100% (28934/28934)\n> Checking out files: 100% (28934/28934), done.\n> Already on 'master'\n> Your branch is up-to-date with 'origin/master'.\n>     On valide le dépôt TestValidation avec la référence:\n> 9b4a485202b2b52922377842c15bfd605d240667\n> HEAD is now at 9b4a485 BUG: On spécifie bash comme shell...\n> \n> But at least 1 file is corrupted!\n> \n> I keep preciously this faulty repo to further investigation with someone who\n> can help dig into the coredump and correct it...\n\nSo _if_ my guess is right that you have filesystem corruption, git may\nnot even know about it. It wrote the file, and the OS said \"OK,\nsuccess\", not knowing it had been partially corrupted.\n\nAnd if that guess is right, it also means there's no git bug to fix.\nSIGBUS is the natural way for the OS to tell the process that mmap'd\ndata isn't available.\n\n-Peff\n"},{"id":"285510","messageId":"572A5D85.8040203@giref.ulaval.ca","threadId":"42025","inReplyTo":"20160422051111.GA32107@sigill.intra.peff.net","subject":"Re: git status core dump with bad sector!","fromName":"Eric Chamberland","fromEmail":"eric.chamberland@giref.ulaval.ca","sentAt":"2016-05-04T20:37:25Z","receivedAt":"2016-05-04T20:37:25Z","isPatch":false,"sender":{"key":"eric.chamberland@giref.ulaval.ca","avatar":null},"body":"Hi,\n\nsorry for the delay...\n\nOn 22/04/16 01:11 AM, Jeff King wrote:\n> On Thu, Apr 14, 2016 at 10:59:57AM -0400, Eric Chamberland wrote:\n>\n>> just cloned a repo and it checked-out wihtout any error (with git 2.2.0) but\n>> got come corrupted files (because I got some sdd failures).\n>>\n>> Then, I get a git core dump when trying to \"git status\" into the repo which\n>> have a \"bad sector\" on sdd drive (crypted partition).\n>>\n>> I tried with git 2.2.0 AND git version 2.8.1.185.gdc0db2c.dirty (just\n>> modified the Makefile to remove STRIP part)\n>>\n>> In both cases, I have a  Bus error (core dumped)\n>\n> Interesting. There was a known issue with reading corrupted pack .idx\n> files, but it was fixed in v2.8.0. So this could be a new thing.\n>\n> SIGBUS is somewhat rare, though (usually just accessing unmapped memory\n> should get us a SIGSEGV). What platform are you on? I seem to recall\n> that hardware like ARM that cares about memory alignment is more likely\n> to get a SIGBUS.\n>\nLinux ... 3.7.10-1.45-desktop #1 SMP PREEMPT Tue Dec 16 20:27:58 UTC \n2014 (4c885a1) x86_64 x86_64 x86_64 GNU/Linux\ndf .\nFilesystem                                     1K-blocks      Used \nAvailable Use% Mounted on\n/dev/mapper/cr_ata-ST31000524AS_6VPCXHSW-part1 961430856 699476812 \n213116108  77% /pmi\n\nmodel name      : Intel(R) Xeon(R) CPU           X5690  @ 3.47GHz\n\n>> Program received signal SIGBUS, Bus error.\n>> 0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n>> (gdb) bt\n>> #0  0x00007ffff7866d58 in ?? () from /lib64/libcrypto.so.1.0.0\n>> #1  0x3334d90d8c20f3f0 in ?? ()\n>> #2  0xe59b5a6cd844a601 in ?? ()\n>> #3  0xc587a53f67985ae7 in ?? ()\n>> #4  0x3ce81893e5541777 in ?? ()\n>> #5  0xdeb18349a4b042ea in ?? ()\n>> #6  0x8254de489067ec4b in ?? ()\n>> #7  0x6fbef2439704c81b in ?? ()\n>> #8  0xe0eee2bb385a96da in ?? ()\n>> #9  0x00007ffff6e19ab3 in ?? ()\n>> #10 0x00007fffffffc4d0 in ?? ()\n>> #11 0x000000000000001d in ?? ()\n>> #12 0x00007ffff7863f80 in SHA1_Update () from /lib64/libcrypto.so.1.0.0\n>> #13 0x00000000005102c0 in write_sha1_file_prepare\n>> (buf=buf@entry=0x7ffff6c81000, len=1673936, type=<optimized out>,\n>> sha1=sha1@entry=0x7fffffffc750 \"\\340_~\", hdr=hdr@entry=0x7fffffffc570 \"blob\n>> 1673936\",\n>\n> So I'd assume here that the problem is in accessing the memory in \"buf\".\n> to actually compute the sha1. That is mmap'd data, but the process is\n> fairly bland (mmap however many bytes stat() tells us the file has, and\n> then compute the sha1). You mentioned a bad sector; could it be that the\n> filesystem is corrupted, and the OS is giving us SIGBUS when trying to\n> read unavailable bytes from an mmap'd file?\n\nYes it could be that...\n\n>\n> That would explain the SIGBUS versus SIGSEGV.\n>\n> What happens if you \"cat\" the file in question:\n\nhmmm, it shows the beginning of the file, then ends with:\n\ncat: Avion.Quadratique.cont.vtu.etalon: Input/output error\n\nalso, this appear in /var/log/messages:\n\n2016-05-04T16:33:19.243595-04:00 melkor kernel: [1096660.854161] \nata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0\n2016-05-04T16:33:19.243609-04:00 melkor kernel: [1096660.854165] \nata4.00: irq_stat 0x40000008\n2016-05-04T16:33:19.243610-04:00 melkor kernel: [1096660.854168] \nata4.00: failed command: READ FPDMA QUEUED\n2016-05-04T16:33:19.243611-04:00 melkor kernel: [1096660.854175] \nata4.00: cmd 60/08:00:70:30:c6/00:00:53:00:00/40 tag 0 ncq 4096 in\n2016-05-04T16:33:19.243612-04:00 melkor kernel: [1096660.854175] \n   res 41/40:08:71:30:c6/00:00:53:00:00/00 Emask 0x409 (media error) <F>\n2016-05-04T16:33:19.243613-04:00 melkor kernel: [1096660.854178] \nata4.00: status: { DRDY ERR }\n2016-05-04T16:33:19.243614-04:00 melkor kernel: [1096660.854180] \nata4.00: error: { UNC }\n2016-05-04T16:33:19.340479-04:00 melkor kernel: [1096660.950794] \nata4.00: configured for UDMA/133\n2016-05-04T16:33:19.340484-04:00 melkor kernel: [1096660.950806] sd \n3:0:0:0: [sdb] Unhandled sense code\n2016-05-04T16:33:19.340485-04:00 melkor kernel: [1096660.950809] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:19.340485-04:00 melkor kernel: [1096660.950811] Result: \nhostbyte=DID_OK driverbyte=DRIVER_SENSE\n2016-05-04T16:33:19.340486-04:00 melkor kernel: [1096660.950814] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:19.340486-04:00 melkor kernel: [1096660.950815] Sense \nKey : Medium Error [current] [descriptor]\n2016-05-04T16:33:19.340486-04:00 melkor kernel: [1096660.950819] \nDescriptor sense data with sense descriptors (in hex):\n2016-05-04T16:33:19.340487-04:00 melkor kernel: [1096660.950820] \n  72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00\n2016-05-04T16:33:19.340487-04:00 melkor kernel: [1096660.950829] \n  53 c6 30 71\n2016-05-04T16:33:19.340488-04:00 melkor kernel: [1096660.950834] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:19.340488-04:00 melkor kernel: [1096660.950836] Add. \nSense: Unrecovered read error - auto reallocate failed\n2016-05-04T16:33:19.340489-04:00 melkor kernel: [1096660.950839] sd \n3:0:0:0: [sdb] CDB:\n2016-05-04T16:33:19.340489-04:00 melkor kernel: [1096660.950840] \nRead(10): 28 00 53 c6 30 70 00 00 08 00\n2016-05-04T16:33:19.340489-04:00 melkor kernel: [1096660.950848] \nend_request: I/O error, dev sdb, sector 1405497457\n2016-05-04T16:33:19.340490-04:00 melkor kernel: [1096660.950870] ata4: \nEH complete\n2016-05-04T16:33:22.157550-04:00 melkor kernel: [1096663.764515] \nata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0\n2016-05-04T16:33:22.157561-04:00 melkor kernel: [1096663.764519] \nata4.00: irq_stat 0x40000008\n2016-05-04T16:33:22.157563-04:00 melkor kernel: [1096663.764522] \nata4.00: failed command: READ FPDMA QUEUED\n2016-05-04T16:33:22.157564-04:00 melkor kernel: [1096663.764529] \nata4.00: cmd 60/08:00:70:30:c6/00:00:53:00:00/40 tag 0 ncq 4096 in\n2016-05-04T16:33:22.157565-04:00 melkor kernel: [1096663.764529] \n   res 41/40:08:71:30:c6/00:00:53:00:00/00 Emask 0x409 (media error) <F>\n2016-05-04T16:33:22.157566-04:00 melkor kernel: [1096663.764532] \nata4.00: status: { DRDY ERR }\n2016-05-04T16:33:22.157567-04:00 melkor kernel: [1096663.764534] \nata4.00: error: { UNC }\n2016-05-04T16:33:22.180479-04:00 melkor kernel: [1096663.787215] \nata4.00: configured for UDMA/133\n2016-05-04T16:33:22.180485-04:00 melkor kernel: [1096663.787225] sd \n3:0:0:0: [sdb] Unhandled sense code\n2016-05-04T16:33:22.180486-04:00 melkor kernel: [1096663.787228] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:22.180486-04:00 melkor kernel: [1096663.787230] Result: \nhostbyte=DID_OK driverbyte=DRIVER_SENSE\n2016-05-04T16:33:22.180487-04:00 melkor kernel: [1096663.787232] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:22.180487-04:00 melkor kernel: [1096663.787234] Sense \nKey : Medium Error [current] [descriptor]\n2016-05-04T16:33:22.180487-04:00 melkor kernel: [1096663.787237] \nDescriptor sense data with sense descriptors (in hex):\n2016-05-04T16:33:22.180488-04:00 melkor kernel: [1096663.787238] \n  72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00\n2016-05-04T16:33:22.180488-04:00 melkor kernel: [1096663.787247] \n  53 c6 30 71\n2016-05-04T16:33:22.180489-04:00 melkor kernel: [1096663.787252] sd \n3:0:0:0: [sdb]\n2016-05-04T16:33:22.180489-04:00 melkor kernel: [1096663.787254] Add. \nSense: Unrecovered read error - auto reallocate failed\n2016-05-04T16:33:22.180490-04:00 melkor kernel: [1096663.787256] sd \n3:0:0:0: [sdb] CDB:\n2016-05-04T16:33:22.180490-04:00 melkor kernel: [1096663.787258] \nRead(10): 28 00 53 c6 30 70 00 00 08 00\n2016-05-04T16:33:22.180490-04:00 melkor kernel: [1096663.787266] \nend_request: I/O error, dev sdb, sector 1405497457\n2016-05-04T16:33:22.180491-04:00 melkor kernel: [1096663.787280] ata4: \nEH complete\n\n\n>\n>> #15 0x00000000005159f8 in index_mem (sha1=sha1@entry=0x7fffffffc750\n>> \"\\340_~\", buf=buf@entry=0x7ffff6c81000, size=1673936,\n>> type=type@entry=OBJ_BLOB,\n>>      path=path@entry=0x80a818 \"Ressources/dev/Test.ExportationVTK/Ressources.Avion/Avion.Quadratique.cont.vtu.etalon\",\n>> flags=flags@entry=0) at sha1_file.c:3305\n>\n> Can it show all of the bytes? I guess from the \"size\" field it's too big\n> to manually verify, but \"cat >/dev/null\" should be enough to see if we\n> can read the whole thing.\n>\n>> Ii would have expected git to first gave me an error when checking out the\n>> files!!! Here is the log:\n>>\n>> Checking out files:  99% (28645/28934)\n>> Checking out files: 100% (28934/28934)\n>> Checking out files: 100% (28934/28934), done.\n>> Already on 'master'\n>> Your branch is up-to-date with 'origin/master'.\n>>      On valide le dépôt TestValidation avec la référence:\n>> 9b4a485202b2b52922377842c15bfd605d240667\n>> HEAD is now at 9b4a485 BUG: On spécifie bash comme shell...\n>>\n>> But at least 1 file is corrupted!\n>>\n>> I keep preciously this faulty repo to further investigation with someone who\n>> can help dig into the coredump and correct it...\n>\n> So _if_ my guess is right that you have filesystem corruption, git may\n> not even know about it. It wrote the file, and the OS said \"OK,\n> success\", not knowing it had been partially corrupted.\n\nok, I see...\n>\n> And if that guess is right, it also means there's no git bug to fix.\n> SIGBUS is the natural way for the OS to tell the process that mmap'd\n> data isn't available.\n\ndoh... then forget about this...\n\nThanks for the enlightments! :)\n\nEric\n>\n> -Peff\n>\n"}]}