Re: [PATCH v5 0/5] for-each-ref: introduce seeking functionality via '--start-after'

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

 



On Wed, Jul 16, 2025 at 06:19:32PM -0700, Kyle Lippincott wrote:

> Unfortunately I can't provide great instructions for reproducing this
> locally, because it relies on our internal build stack (which uses
> blaze). Getting MemorySanitizer running can be quite annoying, though
> you might not have any issues if this test doesn't invoke any third
> party libraries (like zlib).
> 
> I need to sign off for the night soon, but if this isn't sufficient
> enough information to identify what's happening here, I can try to dig
> deeper tomorrow. This run was executed on an import of upstream commit
> 4ea3c74afd42a503b3e0d60e1fec33bc0431e7bc (Junio's merge of this
> series)

valgrind can often find the same issues as MSan without as much headache
to get it running (the downside is that it is _way_ slower). And indeed:

  git checkout 4ea3c74afd42a503b3e0d60e1fec33bc0431e7bc &&
  make &&
  (cd t && ./t6302-for-each-ref-filter.sh --valgrind-only=48)

yields:

  ==2177572== Conditional jump or move depends on uninitialised value(s)
  ==2177572==    at 0x3BC380: cache_ref_iterator_advance (ref-cache.c:409)
  ==2177572==    by 0x3B69D7: ref_iterator_advance (iterator.c:15)
  ==2177572==    by 0x3B6CC3: merge_ref_iterator_advance (iterator.c:179)
  ==2177572==    by 0x3B69D7: ref_iterator_advance (iterator.c:15)
  ==2177572==    by 0x3A9770: files_ref_iterator_advance (files-backend.c:902)
  ==2177572==    by 0x3B69D7: ref_iterator_advance (iterator.c:15)
  ==2177572==    by 0x3B7457: do_for_each_ref_iterator (iterator.c:478)
  ==2177572==    by 0x399B43: for_each_fullref_with_seek (ref-filter.c:2718)
  ==2177572==    by 0x399C09: for_each_fullref_in_pattern (ref-filter.c:2756)
  ==2177572==    by 0x39B031: do_filter_refs (ref-filter.c:3263)
  ==2177572==    by 0x39B2B7: filter_and_format_refs (ref-filter.c:3364)
  ==2177572==    by 0x18C1D2: cmd_for_each_ref (for-each-ref.c:115)
  ==2177572==  Uninitialised value was created by a heap allocation
  ==2177572==    at 0x484BDD0: realloc (vg_replace_malloc.c:1801)
  ==2177572==    by 0x44E941: xrealloc (wrapper.c:140)
  ==2177572==    by 0x3BCAD9: cache_ref_iterator_begin (ref-cache.c:580)
  ==2177572==    by 0x3A988A: files_ref_iterator_begin (files-backend.c:995)
  ==2177572==    by 0x3A295E: refs_ref_iterator_begin (refs.c:1776)
  ==2177572==    by 0x399AF6: for_each_fullref_with_seek (ref-filter.c:2710)
  ==2177572==    by 0x399C09: for_each_fullref_in_pattern (ref-filter.c:2756)
  ==2177572==    by 0x39B031: do_filter_refs (ref-filter.c:3263)
  ==2177572==    by 0x39B2B7: filter_and_format_refs (ref-filter.c:3364)
  ==2177572==    by 0x18C1D2: cmd_for_each_ref (for-each-ref.c:115)
  ==2177572==    by 0x128C90: run_builtin (git.c:480)
  ==2177572==    by 0x1290EB: handle_builtin (git.c:746)

Bisecting doesn't tell us much, though (the first commit that introduces
the test shows the problem). I didn't dig further than that.

-Peff




[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