On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson <sand...@crustytoothpaste.net> wrote: > On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote: >> > I have a guess about what the problem might be. Can you try this patch >> > and see if it fixes things? >> >> That does fix the crash. Thanks for the quick diagnosis. >> >> Can the commit message go into more detail as to why this was crashing >> (or your speculation about why)? Perhaps give more detail about what >> 'clone' is doing that led to the crash. > > Sure. I ran into this as I was expanding the hash structure abstraction > into my next series. I'll send a follow-up patch with a more > descriptive answer. > > I'm still extremely puzzled as to why this doesn't fail on Linux. If > it's failing in this case, it should very, very clearly fail all the > time we access an empty blob or an empty tree. I've tried with gcc and > two versions of clang, using -fno-lto, with address sanitizer, with -O0, > and so on. I'd really like to catch this kind of issue sooner in the > future if I can figure out how to reproduce it.
I think it's file system related, case-insensitive one in particular. The call trace posted at the beginning of this thread should never trigger for an initial clone. You only check if an _existing_ entry matches what you are about to checkout when you switch trees. For this to happen at clone time, I suppose you have to checkout entry "A", then re-checkout "A" again. Which can only happen on case-insensitive file systems and a case-sensitive repo where the second "A" might actually be "a". vim-colorschemes.git has these two entries, which meets one of the conditions, I suppose macos meets the other colors/darkblue.vim colors/darkBlue.vim On Linux, after I hacked all over the place to force ce_match_stat() to eventually call index_fd() which in turns must use one of the hashing function, I got a crash. -- Duy
