Re: Crashes in t/t4058-diff-duplicates.sh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano, Fri, May 06, 2022 18:30:34 +0200:
> Alex Riesen <alexander.riesen@xxxxxxxxxxx> writes:
> 
> > Taylor Blau, Fri, May 06, 2022 05:31:12 +0200:
> 
> >> t4058.16, which blames back to ac14de13b2 (t4058: explore duplicate tree
> 
> That commit talks about "trees with duplicate entries".  Does it
> mean a bad history where a tree object has two or more entries under
> the same name?  We should of course be catching these things at fsck
> time and rejecting at network transfer time, but I agree it is not a
> good excuse for us to segfault.  We should diagnose it as a broken
> tree object and actively refuse to proceed by calling die().

There seem to be multiple places (according to the the commit above, and these
tests on my machine find two) where something crashes, and while one is easy to
plug with a simple if-NULL check:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055786ef58a00 in traverse_by_cache_tree (info=0x7fff87d1f400,
    info=0x7fff87d1f400, nr_names=1, nr_entries=4, pos=0)
    at unpack-trees.c:807
807                     len = ce_namelen(src[0]); <--- src[0] is NULL


the other case seems to be more involved:

#0  verify_one (r=r@entry=0x5555e70aeaa0 <the_repo>,
    istate=istate@entry=0x5555e70ae980 <the_index>, it=0x5555e839ab90,
    path=path@entry=0x7ffedea66570) at cache-tree.c:929
929                     if (ce->ce_flags & (CE_STAGEMASK | CE_INTENT_TO_ADD | CE_REMOVE))
(ce cannot be resolved) ----^

Threads:
  Id   Target Id                         Frame
* 1    Thread 0x7f26de550740 (LWP 19565) verify_one (r=r@entry=0x5555e70aeaa0 <the_repo>, istate=istate@entry=0x5555e70ae980 <the_index>, it=0x5555e839ab90, path=path@entry=0x7ffedea66570) at cache-tree.c:929
Stack:
ce = 0x5a5a5a5a5a5a5a5a <--- Poisoned pointer?
sub = 0x0
i = 1
pos = 0
len = 6
tree_buf = {
  alloc = 65,
  len = 33,
  buf = 0x5555e839b530 "100644 inner"
}
new_oid = {
  hash = '\000' <repeats 31 times>,
  algo = 0
}
#0  verify_one (r=r@entry=0x5555e70aeaa0 <the_repo>, istate=istate@entry=0x5555e70ae980 <the_index>, it=0x5555e839ab90, path=path@entry=0x7ffedea66570) at cache-tree.c:929
#1  0x00005555e6e43720 in verify_one (r=r@entry=0x5555e70aeaa0 <the_repo>, istate=istate@entry=0x5555e70ae980 <the_index>, it=0x5555e83777b0, path=path@entry=0x7ffedea66570) at cache-tree.c:888
#2  0x00005555e6e44398 in cache_tree_verify (r=0x5555e70aeaa0 <the_repo>, istate=istate@entry=0x5555e70ae980 <the_index>) at cache-tree.c:968
#3  0x00005555e6f10807 in write_locked_index (istate=0x5555e70ae980 <the_index>, lock=lock@entry=0x7ffedea66740, flags=flags@entry=1) at read-cache.c:3332
#4  0x00005555e6df7456 in cmd_reset (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin/reset.c:551
#5  0x00005555e6d5b21b in run_builtin (argv=0x7ffedea67260, argc=2, p=0x5555e707d0a8 <commands+2472>) at git.c:465
...

Ideas?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux