Skip to content

GVFS-2-17-1-2/gvfs-serialize-exclude#11

Merged
jamill merged 3 commits intomicrosoft:gvfs-2.17.1.2from
jeffhostetler:gvfs-2-17-1-2/gvfs-serialize-exclude
Jul 30, 2018
Merged

GVFS-2-17-1-2/gvfs-serialize-exclude#11
jamill merged 3 commits intomicrosoft:gvfs-2.17.1.2from
jeffhostetler:gvfs-2-17-1-2/gvfs-serialize-exclude

Conversation

@jeffhostetler
Copy link

@jeffhostetler jeffhostetler commented Jul 27, 2018

Back port from gvfs-2.18.0.

This PR should only contain the "serialize global and repo-local..." commit. It currently
shows that it also contains the gvfs-serialize-status-rename fix (because gvfs-2.17.1.2
has not yet been advanced to include it).

@jeffhostetler
status: fix rename reporting when using serialization cache
0b5ab45 
Fix "git status --deserialize" to correctly report both pathnames
for renames.  Add a test case to verify.

A change was made upstream that added an additional "rename_status"
field to the "struct wt_status_change_data" structure.  It is used
during the various print routines to decide if 2 pathnames need to
be printed.

    5134ccd
    wt-status.c: rename rename-related fields in wt_status_change_data

The fix here is to add that field to the status cache data.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@jeffhostetler
status: add comments for ahead_behind_flags in serialization
36533b0 
The "ahead_behind_flags" field of "struct wt_status" does not
need to be stored in the serialization cache file, since it is
a display property.  Update the code comments in both serialize
and deserialize to reflect that.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@jeffhostetler
serialize-status: serialize global and repo-local exclude file metadata
cf5f77c 
Changes to the global or repo-local excludes files can change the
results returned by "git status" for untracked files.  Therefore,
it is important that the exclude-file values used during serialization
are still current at the time of deserialization.

Teach "git status --serialize" to report metadata on the user's global
exclude file (which defaults to "$XDG_HOME/git/ignore") and for the
repo-local excludes file (which is in ".git/info/excludes").  Serialize
will record the pathnames and mtimes for these files in the serialization
header (next to the mtime data for the .git/index file).

Teach "git status --deserialize" to validate this new metadata.  If either
exclude file has changed since the serialization-cache-file was written,
then deserialize will reject the cache file and force a full/normal status
run.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
@jeffhostetler jeffhostetler requested a review from a team July 27, 2018 22:20
@jamill jamill merged commit 2962052 into microsoft:gvfs-2.17.1.2 Jul 30, 2018
@jeffhostetler jeffhostetler deleted the gvfs-2-17-1-2/gvfs-serialize-exclude branch July 1, 2019 18:31
derrickstolee pushed a commit that referenced this pull request Jun 1, 2020
@dscho @derrickstolee
Merge updates to serialized status
99a88a2 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Jul 20, 2020
@dscho @derrickstolee
Merge updates to serialized status
be8ccde 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Jul 27, 2020
@dscho @derrickstolee
Merge updates to serialized status
f5756a6 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Jul 28, 2020
@dscho @derrickstolee
Merge updates to serialized status
0d6f16c 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 6, 2020
@dscho @derrickstolee
Merge updates to serialized status
49f9385 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 6, 2020
@dscho @derrickstolee
Merge updates to serialized status
1b40ae7 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Oct 6, 2020
@dscho
Merge updates to serialized status
01ec887 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 9, 2020
@dscho @derrickstolee
Merge updates to serialized status
5d14a58 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 9, 2020
@dscho @derrickstolee
Merge updates to serialized status
89daca9 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 16, 2020
@dscho @derrickstolee
Merge updates to serialized status
a90c086 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Oct 19, 2020
@dscho @derrickstolee
Merge updates to serialized status
ae0c595 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
mjcheetham pushed a commit that referenced this pull request Dec 15, 2020
@dscho @mjcheetham
Merge updates to serialized status
15bd00f 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
mjcheetham pushed a commit that referenced this pull request Dec 15, 2020
@dscho @mjcheetham
Merge updates to serialized status
529433a 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Dec 18, 2020
@dscho
Merge updates to serialized status
673284d 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Dec 24, 2020
@dscho
Merge updates to serialized status
a88c497 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Dec 28, 2020
@dscho
Merge updates to serialized status
910b645 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Mar 4, 2021
@dscho
Merge updates to serialized status
58ed213 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Mar 4, 2021
@dscho
Merge updates to serialized status
60e2aeb 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Mar 4, 2021
@dscho
Merge updates to serialized status
51bff81 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Mar 5, 2021
@dscho
Merge updates to serialized status
84f3e2a 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
jeffhostetler pushed a commit that referenced this pull request Mar 15, 2021
@dscho @jeffhostetler
Merge updates to serialized status
7ecad33 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
jeffhostetler pushed a commit that referenced this pull request Mar 16, 2021
@dscho @jeffhostetler
Merge updates to serialized status
df35772 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request Mar 29, 2021
@ahunt @gitster
fsmonitor: avoid global-buffer-overflow READ when checking trivial re…
097ea2c 
…sponse

query_result can be be an empty strbuf (STRBUF_INIT) - in that case
trying to read 3 bytes triggers a buffer overflow read (as
query_result.buf = '\0').

Therefore we need to check query_result's length before trying to read 3
bytes.

This overflow was introduced in:
  940b94f (fsmonitor: log invocation of FSMonitor hook to trace2, 2021-02-03)
It was found when running the test-suite against ASAN, and can be most
easily reproduced with the following command:

make GIT_TEST_OPTS="-v" DEFAULT_TEST_TARGET="t7519-status-fsmonitor.sh" \
SANITIZE=address DEVELOPER=1 test

==2235==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000019e6e5e at pc 0x00000043745c bp 0x7fffd382c520 sp 0x7fffd382bcc8
READ of size 3 at 0x0000019e6e5e thread T0
    #0 0x43745b in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:842:7
    #1 0x43786d in bcmp /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:887:10
    #2 0x80b146 in fsmonitor_is_trivial_response /home/ahunt/oss-fuzz/git/fsmonitor.c:192:10
    #3 0x80b146 in query_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:175:7
    #4 0x80a749 in refresh_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:267:21
    #5 0x80bad1 in tweak_fsmonitor /home/ahunt/oss-fuzz/git/fsmonitor.c:429:4
    #6 0x90f040 in read_index_from /home/ahunt/oss-fuzz/git/read-cache.c:2321:3
    #7 0x8e5d08 in repo_read_index_preload /home/ahunt/oss-fuzz/git/preload-index.c:164:15
    #8 0x52dd45 in prepare_index /home/ahunt/oss-fuzz/git/builtin/commit.c:363:6
    #9 0x52a188 in cmd_commit /home/ahunt/oss-fuzz/git/builtin/commit.c:1588:15
    #10 0x4ce77e in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    #11 0x4ccb18 in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    #12 0x4cb01c in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    #13 0x4cb01c in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    #14 0x6aca8d in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    #15 0x7fb027bf5349 in __libc_start_main (/lib64/libc.so.6+0x24349)
    #16 0x4206b9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.26/csu/../sysdeps/x86_64/start.S:120

0x0000019e6e5e is located 2 bytes to the left of global variable 'strbuf_slopbuf' defined in 'strbuf.c:51:6' (0x19e6e60) of size 1
  'strbuf_slopbuf' is ascii string ''
0x0000019e6e5e is located 126 bytes to the right of global variable 'signals' defined in 'sigchain.c:11:31' (0x19e6be0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:842:7 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long)
Shadow bytes around the buggy address:
  0x000080334d70: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x000080334d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080334d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080334da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080334db0: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
=>0x000080334dc0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9[f9]01 f9 f9 f9
  0x000080334dd0: f9 f9 f9 f9 03 f9 f9 f9 f9 f9 f9 f9 02 f9 f9 f9
  0x000080334de0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x000080334df0: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x000080334e00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 01 f9 f9 f9
  0x000080334e10: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Acked-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
derrickstolee pushed a commit that referenced this pull request May 17, 2021
@dscho @derrickstolee
Merge updates to serialized status
0f037f7 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request May 17, 2021
@dscho @derrickstolee
Merge updates to serialized status
43bb7c7 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request May 17, 2021
@dscho @derrickstolee
Merge updates to serialized status
7a0b8f0 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request May 21, 2021
@dscho
Merge updates to serialized status
73bdef6 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request May 22, 2021
@dscho
Merge updates to serialized status
b0d5ffe 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee pushed a commit that referenced this pull request May 28, 2021
@dscho @derrickstolee
Merge updates to serialized status
88e2eaa 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
dscho added a commit that referenced this pull request Jun 2, 2021
@dscho
Merge updates to serialized status
69eca5d 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
symbolic-ref: don't leak shortened refname in check_symref()
f63b888 
shorten_unambiguous_ref() returns an allocated string. We have to
track it separately from the const refname.

This leak has existed since:
9ab55da (git symbolic-ref --delete $symref, 2012-10-21)

This leak was found when running t0001 with LSAN, see also LSAN output
below:

Direct leak of 19 byte(s) in 1 object(s) allocated from:
    #0 0x486514 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0x9ab048 in xstrdup /home/ahunt/oss-fuzz/git/wrapper.c:29:14
    microsoft#2 0x8b452f in refs_shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c
    microsoft#3 0x8b47e8 in shorten_unambiguous_ref /home/ahunt/oss-fuzz/git/refs.c:1287:9
    microsoft#4 0x679fce in check_symref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:28:14
    microsoft#5 0x679ad8 in cmd_symbolic_ref /home/ahunt/oss-fuzz/git/builtin/symbolic-ref.c:70:9
    microsoft#6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#10 0x69cc6e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#11 0x7f98388a4349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
reset: free instead of leaking unneeded ref
e901de6 
dwim_ref() allocs a new string into ref. Instead of setting to NULL to
discard it, we can FREE_AND_NULL.

This leak appears to have been introduced in:
4cf76f6 (builtin/reset: compute checkout metadata for reset, 2020-03-16)

This leak was found when running t0001 with LSAN, see also LSAN output below:

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x486514 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0x9a7108 in xstrdup /home/ahunt/oss-fuzz/git/wrapper.c:29:14
    microsoft#2 0x8add6b in expand_ref /home/ahunt/oss-fuzz/git/refs.c:670:12
    microsoft#3 0x8ad777 in repo_dwim_ref /home/ahunt/oss-fuzz/git/refs.c:644:22
    microsoft#4 0x6394af in dwim_ref /home/ahunt/oss-fuzz/git/./refs.h:162:9
    microsoft#5 0x637e5c in cmd_reset /home/ahunt/oss-fuzz/git/builtin/reset.c:426:4
    microsoft#6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#10 0x69c5ce in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#11 0x7f57ebb9d349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
clone: free or UNLEAK further pointers when finished
0c45427 
Most of these pointers can safely be freed when cmd_clone() completes,
therefore we make sure to free them. The one exception is that we
have to UNLEAK(repo) because it can point either to argv[0], or a
malloc'd string returned by absolute_pathdup().

We also have to free(path) in the middle of cmd_clone(): later during
cmd_clone(), path is unconditionally overwritten with a different path,
triggering a leak. Freeing the first path immediately after use (but
only in the case where it contains data) seems like the cleanest
solution, as opposed to freeing it unconditionally before path is reused
for another path. This leak appears to have been introduced in:
  f38aa83 (use local cloning if insteadOf makes a local URL, 2014-07-17)

These leaks were found when running t0001 with LSAN, see also an excerpt
of the LSAN output below (the full list is omitted because it's far too
long, and mostly consists of indirect leakage of members of the refs we
are freeing).

Direct leak of 178 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9a6ff4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    microsoft#2 0x9a6fca in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    microsoft#3 0x8ce296 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    microsoft#4 0x8d2ebd in guess_remote_head /home/ahunt/oss-fuzz/git/remote.c:2215:10
    microsoft#5 0x51d0c5 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1308:4
    microsoft#6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#10 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#11 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9a6fc4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    microsoft#2 0x9a6f9a in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    microsoft#3 0x8ce266 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    microsoft#4 0x51e9bd in wanted_peer_refs /home/ahunt/oss-fuzz/git/builtin/clone.c:574:21
    microsoft#5 0x51cfe1 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1284:17
    microsoft#6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#10 0x69c42e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#11 0x7f8fef0c2349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 178 byte(s) in 1 object(s) allocated from:
    #0 0x49a53d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9a6ff4 in do_xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:41:8
    microsoft#2 0x9a6fca in xmalloc /home/ahunt/oss-fuzz/git/wrapper.c:62:9
    microsoft#3 0x8ce296 in copy_ref /home/ahunt/oss-fuzz/git/remote.c:885:8
    microsoft#4 0x8d2ebd in guess_remote_head /home/ahunt/oss-fuzz/git/remote.c:2215:10
    microsoft#5 0x51d0c5 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1308:4
    microsoft#6 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#7 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#8 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#9 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#10 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#11 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a6b2 in calloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    microsoft#1 0x9a72f2 in xcalloc /home/ahunt/oss-fuzz/git/wrapper.c:140:8
    microsoft#2 0x8ce203 in alloc_ref_with_prefix /home/ahunt/oss-fuzz/git/remote.c:867:20
    microsoft#3 0x8ce1a2 in alloc_ref /home/ahunt/oss-fuzz/git/remote.c:875:9
    microsoft#4 0x72f63e in process_ref_v2 /home/ahunt/oss-fuzz/git/connect.c:426:8
    microsoft#5 0x72f21a in get_remote_refs /home/ahunt/oss-fuzz/git/connect.c:525:8
    microsoft#6 0x979ab7 in handshake /home/ahunt/oss-fuzz/git/transport.c:305:4
    microsoft#7 0x97872d in get_refs_via_connect /home/ahunt/oss-fuzz/git/transport.c:339:9
    microsoft#8 0x9774b5 in transport_get_remote_refs /home/ahunt/oss-fuzz/git/transport.c:1388:4
    microsoft#9 0x51cf80 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1271:9
    microsoft#10 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#11 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#12 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#13 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#14 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#15 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 105 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9a71f6 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    microsoft#2 0x93622d in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    microsoft#3 0x937a73 in strbuf_addch /home/ahunt/oss-fuzz/git/./strbuf.h:231:3
    microsoft#4 0x939fcd in strbuf_add_absolute_path /home/ahunt/oss-fuzz/git/strbuf.c:911:4
    microsoft#5 0x69d3ce in absolute_pathdup /home/ahunt/oss-fuzz/git/abspath.c:261:2
    microsoft#6 0x51c688 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1021:10
    microsoft#7 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#8 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#9 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#10 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#11 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#12 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
worktree: fix leak in dwim_branch()
aa1b639 
Make sure that we release the temporary strbuf during dwim_branch() for
all codepaths (and not just for the early return).

This leak appears to have been introduced in:
  f60a7b7 (worktree: teach "add" to check out existing branches, 2018-04-24)

Note that UNLEAK(branchname) is still needed: the returned result is
used in add(), and is stored in a pointer which is used to point at one
of:
  - a string literal ("HEAD")
  - member of argv (whatever the user specified in their invocation)
  - or our newly allocated string returned from dwim_branch()
Fixing the branchname leak isn't impossible, but does not seem
worthwhile given that add() is called directly from cmd_main(), and
cmd_main() returns immediately thereafter - UNLEAK is good enough.

This leak was found when running t0001 with LSAN, see also LSAN output
below:

Direct leak of 60 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9ab076 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    microsoft#2 0x939fcd in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    microsoft#3 0x93af53 in strbuf_splice /home/ahunt/oss-fuzz/git/strbuf.c:239:3
    microsoft#4 0x83559a in strbuf_check_branch_ref /home/ahunt/oss-fuzz/git/object-name.c:1593:2
    microsoft#5 0x6988b9 in dwim_branch /home/ahunt/oss-fuzz/git/builtin/worktree.c:454:20
    microsoft#6 0x695f8f in add /home/ahunt/oss-fuzz/git/builtin/worktree.c:525:19
    microsoft#7 0x694a04 in cmd_worktree /home/ahunt/oss-fuzz/git/builtin/worktree.c:1036:10
    microsoft#8 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#9 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#10 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#11 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#12 0x69caee in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#13 0x7f7b7dd10349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
init: remove git_init_db_config() while fixing leaks
e4de450 
The primary goal of this change is to stop leaking init_db_template_dir.
This leak can happen because:
 1. git_init_db_config() allocates new memory into init_db_template_dir
    without first freeing the existing value.
 2. init_db_template_dir might already contain data, either because:
  2.1 git_config() can be invoked twice with this callback in a single
      process - at least 2 allocations are likely.
  2.2 A single git_config() allocation can invoke the callback multiple
      times for a given key (see further explanation in the function
      docs) - each of those calls will trigger another leak.

The simplest fix for the leak would be to free(init_db_template_dir)
before overwriting it. Instead we choose to convert to fetching
init.templatedir via git_config_get_value() as that is more explicit,
more efficient, and avoids allocations (the returned result is owned by
the config cache, so we aren't responsible for freeing it).

If we remove init_db_template_dir, git_init_db_config() ends up being
responsible only for forwarding core.* config values to
platform_core_config(). However platform_core_config() already ignores
non-core.* config values, so we can safely remove git_init_db_config()
and invoke git_config() directly with platform_core_config() as the
callback.

The platform_core_config forwarding was originally added in:
  2878533 (mingw: respect core.hidedotfiles = false in git-init again, 2019-03-11
And I suspect the potential for a leak existed since the original
implementation of git_init_db_config in:
  90b4518 (Add `init.templatedir` configuration variable., 2010-02-17)

LSAN output from t0001:

Direct leak of 73 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9a7276 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    microsoft#2 0x9362ad in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    microsoft#3 0x936eaa in strbuf_add /home/ahunt/oss-fuzz/git/strbuf.c:295:2
    microsoft#4 0x868112 in strbuf_addstr /home/ahunt/oss-fuzz/git/./strbuf.h:304:2
    microsoft#5 0x86a8ad in expand_user_path /home/ahunt/oss-fuzz/git/path.c:758:2
    microsoft#6 0x720bb1 in git_config_pathname /home/ahunt/oss-fuzz/git/config.c:1287:10
    microsoft#7 0x5960e2 in git_init_db_config /home/ahunt/oss-fuzz/git/builtin/init-db.c:161:11
    microsoft#8 0x7255b8 in configset_iter /home/ahunt/oss-fuzz/git/config.c:1982:7
    microsoft#9 0x7253fc in repo_config /home/ahunt/oss-fuzz/git/config.c:2311:2
    microsoft#10 0x725ca7 in git_config /home/ahunt/oss-fuzz/git/config.c:2399:2
    microsoft#11 0x593e8d in create_default_files /home/ahunt/oss-fuzz/git/builtin/init-db.c:225:2
    microsoft#12 0x5935c6 in init_db /home/ahunt/oss-fuzz/git/builtin/init-db.c:449:11
    microsoft#13 0x59588e in cmd_init_db /home/ahunt/oss-fuzz/git/builtin/init-db.c:714:9
    microsoft#14 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#15 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#16 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#17 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#18 0x69c4de in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#19 0x7f23552d6349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
parse-options: don't leak alias help messages
64cc539 
preprocess_options() allocates new strings for help messages for
OPTION_ALIAS. Therefore we also need to clean those help messages up
when freeing the returned options.

First introduced in:
  7c28058 (parse-options: teach "git cmd -h" to show alias as alias, 2020-03-16)

The preprocessed options themselves no longer contain any indication
that a given option is/was an alias - therefore we add a new flag to
indicate former aliases. (An alternative approach would be to look back
at the original options to determine which options are aliases - but
that seems like a fragile approach. Or we could even look at the
alias_groups list - which might be less fragile, but would be slower
as it requires nested looping.)

As far as I can tell, parse_options() is only ever used once per
command, and the help messages are small - hence this leak has very
little impact.

This leak was found while running t0001. LSAN output can be found below:

Direct leak of 65 byte(s) in 1 object(s) allocated from:
    #0 0x49a859 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9aae36 in xrealloc /home/ahunt/oss-fuzz/git/wrapper.c:126:8
    microsoft#2 0x939d8d in strbuf_grow /home/ahunt/oss-fuzz/git/strbuf.c:98:2
    microsoft#3 0x93b936 in strbuf_vaddf /home/ahunt/oss-fuzz/git/strbuf.c:392:3
    microsoft#4 0x93b7ff in strbuf_addf /home/ahunt/oss-fuzz/git/strbuf.c:333:2
    microsoft#5 0x86747e in preprocess_options /home/ahunt/oss-fuzz/git/parse-options.c:666:3
    microsoft#6 0x866ed2 in parse_options /home/ahunt/oss-fuzz/git/parse-options.c:847:17
    microsoft#7 0x51c4a7 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:989:9
    microsoft#8 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#9 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#10 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#11 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#12 0x69c9fe in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#13 0x7fdac42d4349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
transport: also free remote_refs in transport_disconnect()
68ffe09 
transport_get_remote_refs() can populate the transport struct's
remote_refs. transport_disconnect() is already responsible for most of
transport's cleanup - therefore we also take care of freeing remote_refs
there.

There are 2 locations where transport_disconnect() is called before
we're done using the returned remote_refs. This patch changes those
callsites to only call transport_disconnect() after the returned refs
are no longer being used - which is necessary to safely be able to
free remote_refs during transport_disconnect().

This commit fixes the following leak which was found while running
t0000, but is expected to also fix the same pattern of leak in all
locations that use transport_get_remote_refs():

Direct leak of 165 byte(s) in 1 object(s) allocated from:
    #0 0x49a6b2 in calloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    microsoft#1 0x9a72f2 in xcalloc /home/ahunt/oss-fuzz/git/wrapper.c:140:8
    microsoft#2 0x8ce203 in alloc_ref_with_prefix /home/ahunt/oss-fuzz/git/remote.c:867:20
    microsoft#3 0x8ce1a2 in alloc_ref /home/ahunt/oss-fuzz/git/remote.c:875:9
    microsoft#4 0x72f63e in process_ref_v2 /home/ahunt/oss-fuzz/git/connect.c:426:8
    microsoft#5 0x72f21a in get_remote_refs /home/ahunt/oss-fuzz/git/connect.c:525:8
    microsoft#6 0x979ab7 in handshake /home/ahunt/oss-fuzz/git/transport.c:305:4
    microsoft#7 0x97872d in get_refs_via_connect /home/ahunt/oss-fuzz/git/transport.c:339:9
    microsoft#8 0x9774b5 in transport_get_remote_refs /home/ahunt/oss-fuzz/git/transport.c:1388:4
    microsoft#9 0x51cf80 in cmd_clone /home/ahunt/oss-fuzz/git/builtin/clone.c:1271:9
    microsoft#10 0x4cd60d in run_builtin /home/ahunt/oss-fuzz/git/git.c:453:11
    microsoft#11 0x4cb2da in handle_builtin /home/ahunt/oss-fuzz/git/git.c:704:3
    microsoft#12 0x4ccc37 in run_argv /home/ahunt/oss-fuzz/git/git.c:771:4
    microsoft#13 0x4cac29 in cmd_main /home/ahunt/oss-fuzz/git/git.c:902:19
    microsoft#14 0x69c45e in main /home/ahunt/oss-fuzz/git/common-main.c:52:11
    microsoft#15 0x7f6a459d5349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
merge-ort: only do pointer arithmetic for non-empty lists
c1ea48a 
versions could be an empty string_list. In that case, versions->items is
NULL, and we shouldn't be trying to perform pointer arithmetic with it (as
that results in undefined behaviour).

Moreover we only use the results of this calculation once when calling
QSORT. Therefore we choose to skip creating relevant_entries and call
QSORT directly with our manipulated pointers (but only if there's data
requiring sorting). This lets us avoid abusing the string_list API,
and saves us from having to explain why this abuse is OK.

Finally, an assertion is added to make sure that write_tree() is called
with a valid offset.

This issue has probably existed since:
  ee4012d (merge-ort: step 2 of tree writing -- function to create tree object, 2020-12-13)
But it only started occurring during tests since tests started using
merge-ort:
  f3b964a (Add testing with merge-ort merge strategy, 2021-03-20)

For reference - here's the original UBSAN commit that implemented this
check, it sounds like this behaviour isn't actually likely to cause any
issues (but we might as well fix it regardless):
https://reviews.llvm.org/D67122

UBSAN output from t3404 or t5601:

merge-ort.c:2669:43: runtime error: applying zero offset to null pointer
    #0 0x78bb53 in write_tree merge-ort.c:2669:43
    microsoft#1 0x7856c9 in process_entries merge-ort.c:3303:2
    microsoft#2 0x782317 in merge_ort_nonrecursive_internal merge-ort.c:3744:2
    microsoft#3 0x77feef in merge_incore_nonrecursive merge-ort.c:3853:2
    microsoft#4 0x6f6a5c in do_recursive_merge sequencer.c:640:3
    microsoft#5 0x6f6a5c in do_pick_commit sequencer.c:2221:9
    microsoft#6 0x6ef055 in single_pick sequencer.c:4814:9
    microsoft#7 0x6ef055 in sequencer_pick_revisions sequencer.c:4867:10
    microsoft#8 0x4fb392 in run_sequencer revert.c:225:9
    microsoft#9 0x4fa5b0 in cmd_revert revert.c:235:8
    microsoft#10 0x42abd7 in run_builtin git.c:453:11
    microsoft#11 0x429531 in handle_builtin git.c:704:3
    microsoft#12 0x4282fb in run_argv git.c:771:4
    microsoft#13 0x4282fb in cmd_main git.c:902:19
    microsoft#14 0x524b63 in main common-main.c:52:11
    microsoft#15 0x7fc2ca340349 in __libc_start_main (/lib64/libc.so.6+0x24349)
    microsoft#16 0x4072b9 in _start start.S:120

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior merge-ort.c:2669:43 in

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
revision: free remainder of old commit list in limit_list
db69bf6 
limit_list() iterates over the original revs->commits list, and consumes
many of its entries via pop_commit. However we might stop iterating over
the list early (e.g. if we realise that the rest of the list is
uninteresting). If we do stop iterating early, list will be pointing to
the unconsumed portion of revs->commits - and we need to free this list
to avoid a leak. (revs->commits itself will be an invalid pointer: it
will have been free'd during the first pop_commit.)

However the list pointer is later reused to iterate over our new list,
but only for the limiting_can_increase_treesame() branch. We therefore
need to introduce a new variable for that branch - and while we're here
we can rename the original list to original_list as that makes its
purpose more obvious.

This leak was found while running t0090. It's not likely to be very
impactful, but it can happen quite early during some checkout
invocations, and hence seems to be worth fixing:

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9ac084 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9ac05a in xmalloc wrapper.c:62:9
    microsoft#3 0x7175d6 in commit_list_insert commit.c:540:33
    microsoft#4 0x71800f in commit_list_insert_by_date commit.c:604:9
    microsoft#5 0x8f8d2e in process_parents revision.c:1128:5
    microsoft#6 0x8f2f2c in limit_list revision.c:1418:7
    microsoft#7 0x8f210e in prepare_revision_walk revision.c:3577:7
    microsoft#8 0x514170 in orphaned_commit_warning builtin/checkout.c:1185:6
    microsoft#9 0x512f05 in switch_branches builtin/checkout.c:1250:3
    microsoft#10 0x50f8de in checkout_branch builtin/checkout.c:1646:9
    microsoft#11 0x50ba12 in checkout_main builtin/checkout.c:2003:9
    microsoft#12 0x5086c0 in cmd_checkout builtin/checkout.c:2055:8
    microsoft#13 0x4cd91d in run_builtin git.c:467:11
    microsoft#14 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#15 0x4ccf47 in run_argv git.c:808:4
    microsoft#16 0x4caf49 in cmd_main git.c:939:19
    microsoft#17 0x69dc0e in main common-main.c:52:11
    microsoft#18 0x7faaabd0e349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 48 byte(s) in 3 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9ac084 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9ac05a in xmalloc wrapper.c:62:9
    microsoft#3 0x717de6 in commit_list_append commit.c:1609:35
    microsoft#4 0x8f1f9b in prepare_revision_walk revision.c:3554:12
    microsoft#5 0x514170 in orphaned_commit_warning builtin/checkout.c:1185:6
    microsoft#6 0x512f05 in switch_branches builtin/checkout.c:1250:3
    microsoft#7 0x50f8de in checkout_branch builtin/checkout.c:1646:9
    microsoft#8 0x50ba12 in checkout_main builtin/checkout.c:2003:9
    microsoft#9 0x5086c0 in cmd_checkout builtin/checkout.c:2055:8
    microsoft#10 0x4cd91d in run_builtin git.c:467:11
    microsoft#11 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#12 0x4ccf47 in run_argv git.c:808:4
    microsoft#13 0x4caf49 in cmd_main git.c:939:19
    microsoft#14 0x69dc0e in main common-main.c:52:11
    microsoft#15 0x7faaabd0e349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
wt-status: fix multiple small leaks
5493ce7 
rev.prune_data is populated (in multiple functions) via copy_pathspec,
and therefore needs to be cleared after running the diff in those
functions.

rev(_info).pending is populated indirectly via setup_revisions, and also
needs to be cleared once diffing is done.

These leaks were found while running t0008 or t0021. The rev.prune_data
leaks are small (80B) but noisy, hence I won't bother including their
logs - the rev.pending leaks are bigger, and can happen early in the
course of other commands, and therefore possibly more valuable to fix -
see example log from a rebase below:

Direct leak of 2048 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9ac2a6 in xrealloc wrapper.c:126:8
    microsoft#2 0x83da03 in add_object_array_with_path object.c:337:3
    microsoft#3 0x8f5d8a in add_pending_object_with_path revision.c:329:2
    microsoft#4 0x8ea50b in add_pending_object_with_mode revision.c:336:2
    microsoft#5 0x8ea4fd in add_pending_object revision.c:342:2
    microsoft#6 0x8ea610 in add_head_to_pending revision.c:354:2
    microsoft#7 0x9b55f5 in has_uncommitted_changes wt-status.c:2474:2
    microsoft#8 0x9b58c4 in require_clean_work_tree wt-status.c:2553:6
    microsoft#9 0x606bcc in cmd_rebase builtin/rebase.c:1970:6
    microsoft#10 0x4cd91d in run_builtin git.c:467:11
    microsoft#11 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#12 0x4ccf47 in run_argv git.c:808:4
    microsoft#13 0x4caf49 in cmd_main git.c:939:19
    microsoft#14 0x69dc0e in main common-main.c:52:11
    microsoft#15 0x7f2d18909349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x486834 in strdup ../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0x9ac048 in xstrdup wrapper.c:29:14
    microsoft#2 0x83da8d in add_object_array_with_path object.c:349:17
    microsoft#3 0x8f5d8a in add_pending_object_with_path revision.c:329:2
    microsoft#4 0x8ea50b in add_pending_object_with_mode revision.c:336:2
    microsoft#5 0x8ea4fd in add_pending_object revision.c:342:2
    microsoft#6 0x8ea610 in add_head_to_pending revision.c:354:2
    microsoft#7 0x9b55f5 in has_uncommitted_changes wt-status.c:2474:2
    microsoft#8 0x9b58c4 in require_clean_work_tree wt-status.c:2553:6
    microsoft#9 0x606bcc in cmd_rebase builtin/rebase.c:1970:6
    microsoft#10 0x4cd91d in run_builtin git.c:467:11
    microsoft#11 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#12 0x4ccf47 in run_argv git.c:808:4
    microsoft#13 0x4caf49 in cmd_main git.c:939:19
    microsoft#14 0x69dc0e in main common-main.c:52:11
    microsoft#15 0x7f2d18909349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 2053 byte(s) leaked in 2 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
ls-files: free max_prefix when done
4c217a4 
common_prefix() returns a new string, which we store in max_prefix -
this string needs to be freed to avoid a leak. This leak is happening
in cmd_ls_files, hence is of no real consequence - an UNLEAK would be
just as good, but we might as well free the string properly.

Leak found while running t0002, see output below:

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x49a85d in malloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9ab1b4 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9ab248 in do_xmallocz wrapper.c:75:8
    microsoft#3 0x9ab22a in xmallocz wrapper.c:83:9
    microsoft#4 0x9ab2d7 in xmemdupz wrapper.c:99:16
    microsoft#5 0x78d6a4 in common_prefix dir.c:191:15
    microsoft#6 0x5aca48 in cmd_ls_files builtin/ls-files.c:669:16
    microsoft#7 0x4cd92d in run_builtin git.c:453:11
    microsoft#8 0x4cb5fa in handle_builtin git.c:704:3
    microsoft#9 0x4ccf57 in run_argv git.c:771:4
    microsoft#10 0x4caf49 in cmd_main git.c:902:19
    microsoft#11 0x69ce2e in main common-main.c:52:11
    microsoft#12 0x7f64d4d94349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
branch: FREE_AND_NULL instead of NULL'ing real_ref
d895804 
real_ref was previously populated by dwim_ref(), which allocates new
memory. We need to make sure to free real_ref when discarding it.
(real_ref is already being freed at the end of create_branch() - but
if we discard it early then it will leak.)

This fixes the following leak found while running t0002-t0099:

Direct leak of 5 byte(s) in 1 object(s) allocated from:
    #0 0x486954 in strdup /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0xdd6484 in xstrdup wrapper.c:29:14
    microsoft#2 0xc0f658 in expand_ref refs.c:671:12
    microsoft#3 0xc0ecf1 in repo_dwim_ref refs.c:644:22
    microsoft#4 0x8b1184 in dwim_ref ./refs.h:162:9
    microsoft#5 0x8b0b02 in create_branch branch.c:284:10
    microsoft#6 0x550cbb in update_refs_for_switch builtin/checkout.c:1046:4
    microsoft#7 0x54e275 in switch_branches builtin/checkout.c:1274:2
    microsoft#8 0x548828 in checkout_branch builtin/checkout.c:1668:9
    microsoft#9 0x541306 in checkout_main builtin/checkout.c:2025:9
    microsoft#10 0x5395fa in cmd_checkout builtin/checkout.c:2077:8
    microsoft#11 0x4d02a8 in run_builtin git.c:467:11
    microsoft#12 0x4cbfe9 in handle_builtin git.c:719:3
    microsoft#13 0x4cf04f in run_argv git.c:808:4
    microsoft#14 0x4cb85a in cmd_main git.c:939:19
    microsoft#15 0x820cf6 in main common-main.c:52:11
    microsoft#16 0x7f30bd9dd349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/bugreport: don't leak prefixed filename
4fa2687 
prefix_filename() returns newly allocated memory, and strbuf_addstr()
doesn't take ownership of its inputs. Therefore we have to make sure to
store and free prefix_filename()'s result.

As this leak is in cmd_bugreport(), we could just as well UNLEAK the
prefix - but there's no good reason not to just free it properly. This
leak was found while running t0091, see output below:

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc /home/abuild/rpmbuild/BUILD/llvm-11.0.0.src/build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9acc66 in xrealloc wrapper.c:126:8
    microsoft#2 0x93baed in strbuf_grow strbuf.c:98:2
    microsoft#3 0x93c6ea in strbuf_add strbuf.c:295:2
    microsoft#4 0x69f162 in strbuf_addstr ./strbuf.h:304:2
    microsoft#5 0x69f083 in prefix_filename abspath.c:277:2
    microsoft#6 0x4fb275 in cmd_bugreport builtin/bugreport.c:146:9
    microsoft#7 0x4cd91d in run_builtin git.c:467:11
    microsoft#8 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#9 0x4ccf47 in run_argv git.c:808:4
    microsoft#10 0x4caf49 in cmd_main git.c:939:19
    microsoft#11 0x69df9e in main common-main.c:52:11
    microsoft#12 0x7f523a987349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/check-ignore: clear_pathspec before returning
2656443 
parse_pathspec() allocates new memory into pathspec, therefore we need
to free it when we're done.

An UNLEAK would probably be just as good here - but clear_pathspec() is
not much more work so we might as well use it. check_ignore() is either
called once directly from cmd_check_ignore() (in which case the leak
really doesnt matter), or it can be called multiple times in a loop from
check_ignore_stdin_paths(), in which case we're potentially leaking
multiple times - but even in this scenario the leak is so small as to
have no real consequence.

Found while running t0008:

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9aca44 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9aca1a in xmalloc wrapper.c:62:9
    microsoft#3 0x873c17 in parse_pathspec pathspec.c:582:2
    microsoft#4 0x503eb8 in check_ignore builtin/check-ignore.c:90:2
    microsoft#5 0x5038af in cmd_check_ignore builtin/check-ignore.c:190:17
    microsoft#6 0x4cd91d in run_builtin git.c:467:11
    microsoft#7 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#8 0x4ccf47 in run_argv git.c:808:4
    microsoft#9 0x4caf49 in cmd_main git.c:939:19
    microsoft#10 0x69e43e in main common-main.c:52:11
    microsoft#11 0x7f18bb0dd349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 65 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9acc46 in xrealloc wrapper.c:126:8
    microsoft#2 0x93baed in strbuf_grow strbuf.c:98:2
    microsoft#3 0x93d696 in strbuf_vaddf strbuf.c:392:3
    microsoft#4 0x9400c6 in xstrvfmt strbuf.c:979:2
    microsoft#5 0x940253 in xstrfmt strbuf.c:989:8
    microsoft#6 0x92b72a in prefix_path_gently setup.c:115:15
    microsoft#7 0x87442d in init_pathspec_item pathspec.c:439:11
    microsoft#8 0x873cef in parse_pathspec pathspec.c:589:3
    microsoft#9 0x503eb8 in check_ignore builtin/check-ignore.c:90:2
    microsoft#10 0x5038af in cmd_check_ignore builtin/check-ignore.c:190:17
    microsoft#11 0x4cd91d in run_builtin git.c:467:11
    microsoft#12 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#13 0x4ccf47 in run_argv git.c:808:4
    microsoft#14 0x4caf49 in cmd_main git.c:939:19
    microsoft#15 0x69e43e in main common-main.c:52:11
    microsoft#16 0x7f18bb0dd349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 2 byte(s) in 1 object(s) allocated from:
    #0 0x486834 in strdup ../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0x9ac9e8 in xstrdup wrapper.c:29:14
    microsoft#2 0x874542 in init_pathspec_item pathspec.c:468:20
    microsoft#3 0x873cef in parse_pathspec pathspec.c:589:3
    microsoft#4 0x503eb8 in check_ignore builtin/check-ignore.c:90:2
    microsoft#5 0x5038af in cmd_check_ignore builtin/check-ignore.c:190:17
    microsoft#6 0x4cd91d in run_builtin git.c:467:11
    microsoft#7 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#8 0x4ccf47 in run_argv git.c:808:4
    microsoft#9 0x4caf49 in cmd_main git.c:939:19
    microsoft#10 0x69e43e in main common-main.c:52:11
    microsoft#11 0x7f18bb0dd349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 179 byte(s) leaked in 3 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/checkout: clear pending objects after diffing
52a9436 
add_pending_object() populates rev.pending, we need to take care of
clearing it once we're done.

This code is run close to the end of a checkout, therefore this leak
seems like it would have very little impact. See also LSAN output
from t0020 below:

Direct leak of 2048 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9acc46 in xrealloc wrapper.c:126:8
    microsoft#2 0x83e3a3 in add_object_array_with_path object.c:337:3
    microsoft#3 0x8f672a in add_pending_object_with_path revision.c:329:2
    microsoft#4 0x8eaeab in add_pending_object_with_mode revision.c:336:2
    microsoft#5 0x8eae9d in add_pending_object revision.c:342:2
    microsoft#6 0x5154a0 in show_local_changes builtin/checkout.c:602:2
    microsoft#7 0x513b00 in merge_working_tree builtin/checkout.c:979:3
    microsoft#8 0x512cb3 in switch_branches builtin/checkout.c:1242:9
    microsoft#9 0x50f8de in checkout_branch builtin/checkout.c:1646:9
    microsoft#10 0x50ba12 in checkout_main builtin/checkout.c:2003:9
    microsoft#11 0x5086c0 in cmd_checkout builtin/checkout.c:2055:8
    microsoft#12 0x4cd91d in run_builtin git.c:467:11
    microsoft#13 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#14 0x4ccf47 in run_argv git.c:808:4
    microsoft#15 0x4caf49 in cmd_main git.c:939:19
    microsoft#16 0x69e43e in main common-main.c:52:11
    microsoft#17 0x7f5dd1d50349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 2048 byte(s) leaked in 1 allocation(s).
Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
mailinfo: also free strbuf lists when clearing mailinfo
f3a9680 
mailinfo.p_hdr_info/s_hdr_info are null-terminated lists of strbuf's,
with entries pointing either to NULL or an allocated strbuf. Therefore
we need to free those strbuf's (and not just the data they contain)
whenever we're done with a given entry. (See handle_header() where those
new strbufs are malloc'd.)

Once we no longer need the list (and not just its entries) we can switch
over to strbuf_list_free() instead of manually iterating over the list,
which takes care of those additional details for us. We can only do this
in clear_mailinfo() - in handle_commit_message() we are only clearing the
array contents but want to reuse the array itself, hence we can't use
strbuf_list_free() there.

However, strbuf_list_free() cannot handle a NULL input, and the lists we
are freeing might be NULL. Therefore we add a NULL check in
strbuf_list_free() to make it safe to use with a NULL input (which is a
pattern used by some of the other *_free() functions around git).

Leak output from t0023:

Direct leak of 72 byte(s) in 3 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9ac9f4 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9ac9ca in xmalloc wrapper.c:62:9
    microsoft#3 0x7f6cf7 in handle_header mailinfo.c:205:10
    microsoft#4 0x7f5abf in check_header mailinfo.c:583:4
    microsoft#5 0x7f5524 in mailinfo mailinfo.c:1197:3
    microsoft#6 0x4dcc95 in parse_mail builtin/am.c:1167:6
    microsoft#7 0x4d9070 in am_run builtin/am.c:1732:12
    microsoft#8 0x4d5b7a in cmd_am builtin/am.c:2398:3
    microsoft#9 0x4cd91d in run_builtin git.c:467:11
    microsoft#10 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#11 0x4ccf47 in run_argv git.c:808:4
    microsoft#12 0x4caf49 in cmd_main git.c:939:19
    microsoft#13 0x69e43e in main common-main.c:52:11
    microsoft#14 0x7fc1fadfa349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 72 byte(s) leaked in 3 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/for-each-ref: free filter and UNLEAK sorting.
a317a55 
sorting might be a list allocated in ref_default_sorting() (in this case
it's a fixed single item list, which has nevertheless been xcalloc'd),
or it might be a list allocated in parse_opt_ref_sorting(). In either
case we could free these lists - but instead we UNLEAK as we're at the
end of cmd_for_each_ref. (There's no existing implementation of
clear_ref_sorting(), and writing a loop to free the list seems more
trouble than it's worth.)

filter.with_commit/no_commit are populated via
OPT_CONTAINS/OPT_NO_CONTAINS, both of which create new entries via
parse_opt_commits(), and also need to be free'd or UNLEAK'd. Because
free_commit_list() already exists, we choose to use that over an UNLEAK.

LSAN output from t0041:

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x49a9d2 in calloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    microsoft#1 0x9ac252 in xcalloc wrapper.c:140:8
    microsoft#2 0x8a4a55 in ref_default_sorting ref-filter.c:2486:32
    microsoft#3 0x56c6b1 in cmd_for_each_ref builtin/for-each-ref.c:72:13
    microsoft#4 0x4cd91d in run_builtin git.c:467:11
    microsoft#5 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#6 0x4ccf47 in run_argv git.c:808:4
    microsoft#7 0x4caf49 in cmd_main git.c:939:19
    microsoft#8 0x69dabe in main common-main.c:52:11
    microsoft#9 0x7f2bdc570349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9abf54 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9abf2a in xmalloc wrapper.c:62:9
    microsoft#3 0x717486 in commit_list_insert commit.c:540:33
    microsoft#4 0x8644cf in parse_opt_commits parse-options-cb.c:98:2
    microsoft#5 0x869bb5 in get_value parse-options.c:181:11
    microsoft#6 0x8677dc in parse_long_opt parse-options.c:378:10
    microsoft#7 0x8659bd in parse_options_step parse-options.c:817:11
    microsoft#8 0x867fcd in parse_options parse-options.c:870:10
    microsoft#9 0x56c62b in cmd_for_each_ref builtin/for-each-ref.c:59:2
    microsoft#10 0x4cd91d in run_builtin git.c:467:11
    microsoft#11 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#12 0x4ccf47 in run_argv git.c:808:4
    microsoft#13 0x4caf49 in cmd_main git.c:939:19
    microsoft#14 0x69dabe in main common-main.c:52:11
    microsoft#15 0x7f2bdc570349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/rebase: release git_format_patch_opt too
805b789 
options.git_format_patch_opt can be populated during cmd_rebase's setup,
and will therefore leak on return. Although we could just UNLEAK all of
options, we choose to strbuf_release() the individual member, which matches
the existing pattern (where we're freeing invidual members of options).

Leak found when running t0021:

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9ac296 in xrealloc wrapper.c:126:8
    microsoft#2 0x93b13d in strbuf_grow strbuf.c:98:2
    microsoft#3 0x93bd3a in strbuf_add strbuf.c:295:2
    microsoft#4 0x60ae92 in strbuf_addstr strbuf.h:304:2
    microsoft#5 0x605f17 in cmd_rebase builtin/rebase.c:1759:3
    microsoft#6 0x4cd91d in run_builtin git.c:467:11
    microsoft#7 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#8 0x4ccf47 in run_argv git.c:808:4
    microsoft#9 0x4caf49 in cmd_main git.c:939:19
    microsoft#10 0x69dbfe in main common-main.c:52:11
    microsoft#11 0x7f66dae91349 in __libc_start_main (/lib64/libc.so.6+0x24349)

SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ldennington pushed a commit to ldennington/git that referenced this pull request Jun 2, 2021
@ahunt @gitster
builtin/rm: avoid leaking pathspec and seen
37be119 
parse_pathspec() populates pathspec, hence we need to clear it once it's
no longer needed. seen is xcalloc'd within the same function and
likewise needs to be freed once its no longer needed.

cmd_rm() has multiple early returns, therefore we need to clear or free
as soon as this data is no longer needed, as opposed to doing a cleanup
at the end.

LSAN output from t0020:

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    microsoft#1 0x9ac0a4 in do_xmalloc wrapper.c:41:8
    microsoft#2 0x9ac07a in xmalloc wrapper.c:62:9
    microsoft#3 0x873277 in parse_pathspec pathspec.c:582:2
    microsoft#4 0x646ffa in cmd_rm builtin/rm.c:266:2
    microsoft#5 0x4cd91d in run_builtin git.c:467:11
    microsoft#6 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#7 0x4ccf47 in run_argv git.c:808:4
    microsoft#8 0x4caf49 in cmd_main git.c:939:19
    microsoft#9 0x69dc0e in main common-main.c:52:11
    microsoft#10 0x7f948825b349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 65 byte(s) in 1 object(s) allocated from:
    #0 0x49ab79 in realloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3
    microsoft#1 0x9ac2a6 in xrealloc wrapper.c:126:8
    microsoft#2 0x93b14d in strbuf_grow strbuf.c:98:2
    microsoft#3 0x93ccf6 in strbuf_vaddf strbuf.c:392:3
    microsoft#4 0x93f726 in xstrvfmt strbuf.c:979:2
    microsoft#5 0x93f8b3 in xstrfmt strbuf.c:989:8
    microsoft#6 0x92ad8a in prefix_path_gently setup.c:115:15
    microsoft#7 0x873a8d in init_pathspec_item pathspec.c:439:11
    microsoft#8 0x87334f in parse_pathspec pathspec.c:589:3
    microsoft#9 0x646ffa in cmd_rm builtin/rm.c:266:2
    microsoft#10 0x4cd91d in run_builtin git.c:467:11
    microsoft#11 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#12 0x4ccf47 in run_argv git.c:808:4
    microsoft#13 0x4caf49 in cmd_main git.c:939:19
    microsoft#14 0x69dc0e in main common-main.c:52:11
    microsoft#15 0x7f948825b349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Indirect leak of 15 byte(s) in 1 object(s) allocated from:
    #0 0x486834 in strdup ../projects/compiler-rt/lib/asan/asan_interceptors.cpp:452:3
    microsoft#1 0x9ac048 in xstrdup wrapper.c:29:14
    microsoft#2 0x873ba2 in init_pathspec_item pathspec.c:468:20
    microsoft#3 0x87334f in parse_pathspec pathspec.c:589:3
    microsoft#4 0x646ffa in cmd_rm builtin/rm.c:266:2
    microsoft#5 0x4cd91d in run_builtin git.c:467:11
    microsoft#6 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#7 0x4ccf47 in run_argv git.c:808:4
    microsoft#8 0x4caf49 in cmd_main git.c:939:19
    microsoft#9 0x69dc0e in main common-main.c:52:11
    microsoft#10 0x7f948825b349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Direct leak of 1 byte(s) in 1 object(s) allocated from:
    #0 0x49a9d2 in calloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
    microsoft#1 0x9ac392 in xcalloc wrapper.c:140:8
    microsoft#2 0x647108 in cmd_rm builtin/rm.c:294:9
    microsoft#3 0x4cd91d in run_builtin git.c:467:11
    microsoft#4 0x4cb5f3 in handle_builtin git.c:719:3
    microsoft#5 0x4ccf47 in run_argv git.c:808:4
    microsoft#6 0x4caf49 in cmd_main git.c:939:19
    microsoft#7 0x69dbfe in main common-main.c:52:11
    microsoft#8 0x7f4fac1b0349 in __libc_start_main (/lib64/libc.so.6+0x24349)

Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho added a commit that referenced this pull request Jun 7, 2021
@dscho
Merge updates to serialized status
a18a6d4 
Includes these pull requests:

	#1
	#6
	#10
	#11
	#157
	#212
	#260
	#270

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@jamill jamill jamill approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jeffhostetler @jamill