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

Reply via email to