[bash completion] selectively disable the git bash prompt #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…be useful for your home directory, for example
|
ok, just saw the comment on pull request 11 — we'll try to post our patches to the list… thanks! :) |
asmeurer
pushed a commit
to asmeurer/git
that referenced
this pull request
Jan 9, 2012
pclouds
referenced
this pull request
in TortoiseGit/tgit
Jan 13, 2012
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho
referenced
this pull request
in dscho/git
May 29, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue #12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
dscho
referenced
this pull request
in dscho/git
May 29, 2012
…e makefile. Use this commit message, rewrapped to 76 columns: msysgit: Add the --large-address-aware linker directive to the makefile. This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue #12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
dscho
referenced
this pull request
in dscho/git
May 29, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue #12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
aroben
referenced
this pull request
in aroben/git
Jun 15, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
kusma
pushed a commit
to kusma/git
that referenced
this pull request
Jun 24, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue git#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
kblees
referenced
this pull request
in kblees/git
Oct 24, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
kblees
referenced
this pull request
in kblees/git
Oct 24, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
frogonwheels
referenced
this pull request
in frogonwheels/git
Dec 23, 2012
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
frogonwheels
referenced
this pull request
in frogonwheels/git
Feb 5, 2013
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
frogonwheels
referenced
this pull request
in frogonwheels/git
Feb 5, 2013
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
frogonwheels
referenced
this pull request
in frogonwheels/git
Feb 5, 2013
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
gitster
pushed a commit
that referenced
this pull request
Jun 7, 2013
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue #12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
kblees
referenced
this pull request
in kblees/git
Jun 9, 2013
This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository. The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls. While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t). [PT: Resolves github issue msysgit#12] Signed-off-by: Pierre le Riche <github@pleasedontspam.me> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
gitster
added a commit
that referenced
this pull request
Mar 23, 2015
Hopefully with another batch or two, we would be ready for -rc0 to close this cycle. Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitster
added a commit
that referenced
this pull request
Mar 23, 2015
* master: Post 2.3 cycle (batch #12) Git 2.3.4
avar
added a commit
to avar/git
that referenced
this pull request
Mar 24, 2017
gitster
added a commit
that referenced
this pull request
Mar 29, 2017
gitster
pushed a commit
that referenced
this pull request
Jul 27, 2017
Since commit 612c49e ("credential-cache: add tests for XDG functionality", 17-03-2017), the cygwin build has been failing all the new tests added by that commit. In particular, the 'git credential-cache exit' command, as part of the test cleanup code, has been die-ing with the message: fatal: read error from cache daemon: Connection reset by peer As this git command is part of an && chain in a 'test_when_finished' call, the remaining test cleanup is not happening, so practically all remaining tests fail due to the unexpected presence of various socket files and directories. A simple means of getting the tests to pass, is to simply ignore the failure of 'git credential-cache exit' command and make sure all test cleanup is done. For example, the diff for test #12 would look like: diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh index fd92533ac..87e5001bb 100755 --- a/t/t0301-credential-cache.sh +++ b/t/t0301-credential-cache.sh @@ -17,7 +17,7 @@ helper_test cache test_expect_success 'socket defaults to ~/.cache/git/credential/socket' ' test_when_finished " - git credential-cache exit && + (git credential-cache exit || :) && rmdir -p .cache/git/credential/ " && test_path_is_missing "$HOME/.git-credential-cache" && ... and so on for all remaining tests. While this does indeed make all tests pass, it is not really a solution. As an aside, while looking to debug this issue, I added the '--debug' option to the invocation of the 'git-credential-cache--daemon' child process (see the spawn_daemon() function). This not only fixed the tests, but also stopped git-credential-cache exiting with a failure. Since the only effect of passing '--debug' was to suppress the redirection of stderr to the bit-bucket (/dev/null), I have no idea why this seems to fix the protocol interaction between git and git-credential-cache--daemon. (I did think that maybe it was a timing issue, so I tried sleeping before reading from the daemon on Linux, but that only slowed down the tests!) All descriptions of the "Connection reset by peer" error, that I could find, say that the peer had destroyed the connection before the client attempted to perform I/O on the connection. Since the daemon does not respond to an "exit" message from the client, it just closes the socket and deletes the socket file (via the atexit handler), it seems that the expected result is for the client to receive an EOF. Indeed, this is exactly what seems to be happening on Linux. Also a comment in credential-cache--daemon.c reads: else if (!strcmp(action.buf, "exit")) { /* * It's important that we clean up our socket first, and then * signal the client only once we have finished the cleanup. * Calling exit() directly does this, because we clean up in * our atexit() handler, and then signal the client when our * process actually ends, which closes the socket and gives * them EOF. */ exit(0); } On cygwin this is not the case, at least when not passing --debug to the daemon, and the read following the "exit" gets an error with errno set to ECONNRESET. In order to suppress the fatal exit in this case, check the read error for an ECONNRESET and return as if no data was read from the daemon. This effectively converts an ECONNRESET into an EOF. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fengguang
pushed a commit
to 0day-ci/git
that referenced
this pull request
Jul 28, 2017
Since commit 612c49e ("credential-cache: add tests for XDG functionality", 17-03-2017), the cygwin build has been failing all the new tests added by that commit. In particular, the 'git credential-cache exit' command, as part of the test cleanup code, has been die-ing with the message: fatal: read error from cache daemon: Connection reset by peer As this git command is part of an && chain in a 'test_when_finished' call, the remaining test cleanup is not happening, so practically all remaining tests fail due to the unexpected presence of various socket files and directories. A simple means of getting the tests to pass, is to simply ignore the failure of 'git credential-cache exit' command and make sure all test cleanup is done. For example, the diff for test git#12 would look like: diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh index fd92533ac..87e5001bb 100755 --- a/t/t0301-credential-cache.sh +++ b/t/t0301-credential-cache.sh @@ -17,7 +17,7 @@ helper_test cache test_expect_success 'socket defaults to ~/.cache/git/credential/socket' ' test_when_finished " - git credential-cache exit && + (git credential-cache exit || :) && rmdir -p .cache/git/credential/ " && test_path_is_missing "$HOME/.git-credential-cache" && ... and so on for all remaining tests. While this does indeed make all tests pass, it is not really a solution. As an aside, while looking to debug this issue, I added the '--debug' option to the invocation of the 'git-credential-cache--daemon' child process (see the spawn_daemon() function). This not only fixed the tests, but also stopped git-credential-cache exiting with a failure. Since the only effect of passing '--debug' was to suppress the redirection of stderr to the bit-bucket (/dev/null), I have no idea why this seems to fix the protocol interaction between git and git-credential-cache--daemon. (I did think that maybe it was a timing issue, so I tried sleeping before reading from the daemon on Linux, but that only slowed down the tests!) All descriptions of the "Connection reset by peer" error, that I could find, say that the peer had destroyed the connection before the client attempted to perform I/O on the connection. Since the daemon does not respond to an "exit" message from the client, it just closes the socket and deletes the socket file (via the atexit handler), it seems that the expected result is for the client to receive an EOF. Indeed, this is exactly what seems to be happening on Linux. Also a comment in credential-cache--daemon.c reads: else if (!strcmp(action.buf, "exit")) { /* * It's important that we clean up our socket first, and then * signal the client only once we have finished the cleanup. * Calling exit() directly does this, because we clean up in * our atexit() handler, and then signal the client when our * process actually ends, which closes the socket and gives * them EOF. */ exit(0); } On cygwin this is not the case, at least when not passing --debug to the daemon, and the read following the "exit" gets an error with errno set to ECONNRESET. In order to suppress the fatal exit in this case, check the read error for an ECONNRESET and return as if no data was read from the daemon. This effectively converts an ECONNRESET into an EOF. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
ahunt
added a commit
to ahunt/git
that referenced
this pull request
Feb 19, 2021
write_commit_graph initialises topo_levels using init_topo_level_slab(), next it calls compute_topological_levels() which can cause the slab to grow, we therefore need to clear the slab again using clear_topo_level_slab() when we're done. First introduced in 72a2bfc - which is currently only in master and not on maint. LeakSanitizer output: ==1026==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8 #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) Indirect leak of 524256 byte(s) in 1 object(s) allocated from: #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8 #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s).
ahunt
added a commit
to ahunt/git
that referenced
this pull request
Feb 19, 2021
write_commit_graph initialises topo_levels using init_topo_level_slab(), next it calls compute_topological_levels() which can cause the slab to grow, we therefore need to clear the slab again using clear_topo_level_slab() when we're done. First introduced in 72a2bfc - which is currently only in master and not on maint. LeakSanitizer output: ==1026==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8 #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) Indirect leak of 524256 byte(s) in 1 object(s) allocated from: #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8 #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s). Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
ahunt
added a commit
to ahunt/git
that referenced
this pull request
Feb 19, 2021
write_commit_graph initialises topo_levels using init_topo_level_slab(), next it calls compute_topological_levels() which can cause the slab to grow, we therefore need to clear the slab again using clear_topo_level_slab() when we're done. First introduced in 72a2bfc - which is currently only in master and not on maint. LeakSanitizer output: ==1026==ERROR: LeakSanitizer: detected memory leaks Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x498ae9 in realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 #1 0xafbed8 in xrealloc /src/git/wrapper.c:126:8 #2 0x7966d1 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) Indirect leak of 524256 byte(s) in 1 object(s) allocated from: #0 0x498942 in calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3 #1 0xafc088 in xcalloc /src/git/wrapper.c:140:8 #2 0x796870 in topo_level_slab_at_peek /src/git/commit-graph.c:71:1 #3 0x7965e0 in topo_level_slab_at /src/git/commit-graph.c:71:1 #4 0x78fbf5 in compute_topological_levels /src/git/commit-graph.c:1472:12 #5 0x78c5c3 in write_commit_graph /src/git/commit-graph.c:2456:2 #6 0x535c5f in graph_write /src/git/builtin/commit-graph.c:299:6 #7 0x5350ca in cmd_commit_graph /src/git/builtin/commit-graph.c:337:11 git#8 0x4cddb1 in run_builtin /src/git/git.c:453:11 git#9 0x4cabe2 in handle_builtin /src/git/git.c:704:3 git#10 0x4cd084 in run_argv /src/git/git.c:771:4 git#11 0x4ca424 in cmd_main /src/git/git.c:902:19 git#12 0x707fb6 in main /src/git/common-main.c:52:11 git#13 0x7fee4249383f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) SUMMARY: AddressSanitizer: 524264 byte(s) leaked in 2 allocation(s). Signed-off-by: Andrzej Hunt <ajrhunt@google.com>
avar
added a commit
to avar/git
that referenced
this pull request
Feb 7, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Feb 7, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Feb 8, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Feb 8, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Feb 10, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Mar 6, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Mar 7, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
Mar 7, 2023
* avar/nuke-test_i18ngrep-again: tests with git#17 test_i18ngrep: replace it with 'grep' tests with git#16 test_i18ngrep: replace it with 'grep' tests with git#15 test_i18ngrep: replace it with 'grep' tests with git#14 test_i18ngrep: replace it with 'grep' tests with git#13 test_i18ngrep: replace it with 'grep' tests with git#12 test_i18ngrep: replace it with 'grep' tests with git#11 test_i18ngrep: replace it with 'grep'
avar
added a commit
to avar/git
that referenced
this pull request
May 1, 2023
For those tests that have 12 occurances of 'test_i18ngrep', replace it with 'grep'. Splitting this incremental conversion by number of occurances in the file is arbitrary, but help so keep the commit size down. The 'test_i18ngrep' wrapper has been deprecated since d162b25 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 23, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 23, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 23, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 24, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 24, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 24, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
gitster
pushed a commit
that referenced
this pull request
Aug 24, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 #6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 #8 0x55e075e2edb0 in do_push builtin/push.c:458 #9 0x55e075e2ff7a in cmd_push builtin/push.c:702 #10 0x55e075d8aaf0 in run_builtin git.c:452 #11 0x55e075d8af08 in handle_builtin git.c:706 #12 0x55e075d8b12c in run_argv git.c:770 #13 0x55e075d8b6a0 in cmd_main git.c:905 #14 0x55e075e81f07 in main common-main.c:60 #15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 #17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 25, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Aug 28, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 git#6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 git#8 0x55e075e2edb0 in do_push builtin/push.c:458 git#9 0x55e075e2ff7a in cmd_push builtin/push.c:702 git#10 0x55e075d8aaf0 in run_builtin git.c:452 git#11 0x55e075d8af08 in handle_builtin git.c:706 git#12 0x55e075d8b12c in run_argv git.c:770 git#13 0x55e075d8b6a0 in cmd_main git.c:905 git#14 0x55e075e81f07 in main common-main.c:60 git#15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 git#16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 git#17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com>
gitster
pushed a commit
that referenced
this pull request
Aug 29, 2023
When t5583-push-branches.sh was originally introduced via 425b4d7 (push: introduce '--branches' option, 2023-05-06), it was not leak-free. In fact, the test did not even run correctly until 022fbb6 (t5583: fix shebang line, 2023-05-12), but after applying that patch, we see a failure at t5583.8: ==2529087==ERROR: LeakSanitizer: detected memory leaks Direct leak of 384 byte(s) in 1 object(s) allocated from: #0 0x7fb536330986 in __interceptor_realloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:98 #1 0x55e07606cbf9 in xrealloc wrapper.c:140 #2 0x55e075fb6cb3 in prio_queue_put prio-queue.c:42 #3 0x55e075ec81cb in get_reachable_subset commit-reach.c:917 #4 0x55e075fe9cce in add_missing_tags remote.c:1518 #5 0x55e075fea1e4 in match_push_refs remote.c:1665 #6 0x55e076050a8e in transport_push transport.c:1378 #7 0x55e075e2eb74 in push_with_options builtin/push.c:401 #8 0x55e075e2edb0 in do_push builtin/push.c:458 #9 0x55e075e2ff7a in cmd_push builtin/push.c:702 #10 0x55e075d8aaf0 in run_builtin git.c:452 #11 0x55e075d8af08 in handle_builtin git.c:706 #12 0x55e075d8b12c in run_argv git.c:770 #13 0x55e075d8b6a0 in cmd_main git.c:905 #14 0x55e075e81f07 in main common-main.c:60 #15 0x7fb5360ab6c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #16 0x7fb5360ab784 in __libc_start_main_impl ../csu/libc-start.c:360 #17 0x55e075d88f40 in _start (git+0x1ff40) (BuildId: 38ad998b85a535e786129979443630d025ec2453) SUMMARY: LeakSanitizer: 384 byte(s) leaked in 1 allocation(s). This leak was addressed independently via 68b5117 (commit-reach: fix memory leak in get_reachable_subset(), 2023-06-03), which makes t5583 leak-free. But t5583 was not in the tree when 68b5117 was written, and the two only met after the latter was merged back in via 693bde4 (Merge branch 'mh/commit-reach-get-reachable-plug-leak', 2023-06-20). At that point, t5583 was leak-free. Let's mark it as such accordingly. Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
vdye
pushed a commit
to vdye/git
that referenced
this pull request
Jan 9, 2024
When I was playing around with trace2 data and creating flamegraphs, I tried a `git fetch` call to see how the `git-remote-https` command would show up. What I didn't expect was an `ensure_full_index()` region! It turns out that `git fetch` and `git pull` need to check the index for a `.gitmodules` file to see if it should recurse into any submodules. Here is the stack trace from a debugger: ``` #0 ensure_full_index (istate=0x555555ac1c80 <the_index>) at sparse-index.c:404 #1 0x000055555571a979 in do_read_index (istate=istate@entry=0x555555ac1c80 <the_index>, path=path@entry=0x555555ad7b90 ".git/index", must_exist=must_exist@entry=0) at read-cache.c:2386 #2 0x000055555571eb7d in do_read_index (must_exist=0, path=0x555555ad7b90 ".git/index", istate=0x555555ac1c80 <the_index>) at hash.h:244 #3 read_index_from (istate=0x555555ac1c80 <the_index>, path=0x555555ad7b90 ".git/index", gitdir=0x555555ad7b30 ".git") at read-cache.c:2426 #4 0x000055555573f4c2 in repo_read_index (repo=repo@entry=0x555555ac1da0 <the_repo>) at repository.c:286 #5 0x00005555556f14d0 in get_oid_with_context_1 (repo=repo@entry=0x555555ac1da0 <the_repo>, name=name@entry=0x55555582c022 ":.gitmodules", flags=flags@entry=0, prefix=prefix@entry=0x0, oid=oid@entry=0x7fffffffdb00, oc=oc@entry=0x7fffffffda70) at object-name.c:1850 git#6 0x00005555556f1f53 in get_oid_with_context (oc=0x7fffffffda70, oid=0x7fffffffdb00, flags=0, str=0x55555582c022 ":.gitmodules", repo=0x555555ac1da0 <the_repo>) at object-name.c:1947 #7 repo_get_oid (r=r@entry=0x555555ac1da0 <the_repo>, name=name@entry=0x55555582c022 ":.gitmodules", oid=oid@entry=0x7fffffffdb00) at object-name.c:1603 git#8 0x000055555577330f in config_from_gitmodules (fn=fn@entry=0x555555773460 <gitmodules_fetch_config>, repo=0x555555ac1da0 <the_repo>, data=data@entry=0x7fffffffdb60) at submodule-config.c:650 git#9 0x000055555577462d in config_from_gitmodules (data=0x7fffffffdb60, repo=<optimized out>, fn=0x555555773460 <gitmodules_fetch_config>) at submodule-config.c:638 git#10 fetch_config_from_gitmodules (max_children=<optimized out>, recurse_submodules=<optimized out>) at submodule-config.c:800 git#11 0x00005555555b9e41 in cmd_fetch (argc=1, argv=0x7fffffffe090, prefix=0x0) at builtin/fetch.c:1999 git#12 0x0000555555573ff6 in run_builtin (argv=<optimized out>, argc=<optimized out>, p=<optimized out>) at git.c:528 git#13 handle_builtin (argc=<optimized out>, argv=<optimized out>) at git.c:785 git#14 0x000055555557528c in run_argv (argv=0x7fffffffddf0, argcp=0x7fffffffddfc) at git.c:857 git#15 cmd_main (argc=<optimized out>, argv=<optimized out>) at git.c:993 git#16 0x0000555555573ac8 in main (argc=3, argv=0x7fffffffe088) at common-main.c:52 ``` The operations these commands use are guarded by items such as `index_name_pos()` and others. Since the `.gitmodules` file is always at root, we would not need to expand, anyway.
gitster
added a commit
that referenced
this pull request
May 28, 2024
spectral54
added a commit
to spectral54/git
that referenced
this pull request
Jun 12, 2024
Memory sanitizer (msan) is detecting a use of an uninitialized variable
(`size`) in `read_attr_from_index`:
==2268==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x5651f3416504 in read_attr_from_index git/attr.c:868:11
#1 0x5651f3415530 in read_attr git/attr.c
#2 0x5651f3413d74 in bootstrap_attr_stack git/attr.c:968:6
#3 0x5651f3413d74 in prepare_attr_stack git/attr.c:1004:2
#4 0x5651f3413d74 in collect_some_attrs git/attr.c:1199:2
#5 0x5651f3413144 in git_check_attr git/attr.c:1345:2
git#6 0x5651f34728da in convert_attrs git/convert.c:1320:2
#7 0x5651f3473425 in would_convert_to_git_filter_fd git/convert.c:1373:2
git#8 0x5651f357a35e in index_fd git/object-file.c:2630:34
git#9 0x5651f357aa15 in index_path git/object-file.c:2657:7
git#10 0x5651f35db9d9 in add_to_index git/read-cache.c:766:7
git#11 0x5651f35dc170 in add_file_to_index git/read-cache.c:799:9
git#12 0x5651f321f9b2 in add_files git/builtin/add.c:346:7
git#13 0x5651f321f9b2 in cmd_add git/builtin/add.c:565:18
git#14 0x5651f321d327 in run_builtin git/git.c:474:11
git#15 0x5651f321bc9e in handle_builtin git/git.c:729:3
git#16 0x5651f321a792 in run_argv git/git.c:793:4
git#17 0x5651f321a792 in cmd_main git/git.c:928:19
git#18 0x5651f33dde1f in main git/common-main.c:62:11
The issue exists because `size` is an output parameter from
`read_blob_data_from_index`, but it's only modified if
`read_blob_data_from_index` returns non-NULL. The read of `size` when
calling `read_attr_from_buf` unconditionally may read from an
uninitialized value. `read_attr_from_buf` checks that `buf` is non-NULL
before reading from `size`, but by then it's already too late: the
uninitialized read will have happened already. Furthermore, there's no
guarantee that the compiler won't reorder things so that it checks
`size` before checking `!buf`.
Make the call to `read_attr_from_buf` conditional on `buf` being
non-NULL, ensuring that `size` is not read if it's never set.
Signed-off-by: Kyle Lippincott <spectral@google.com>
gitster
pushed a commit
that referenced
this pull request
Jun 17, 2024
Memory sanitizer (msan) is detecting a use of an uninitialized variable
(`size`) in `read_attr_from_index`:
==2268==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x5651f3416504 in read_attr_from_index git/attr.c:868:11
#1 0x5651f3415530 in read_attr git/attr.c
#2 0x5651f3413d74 in bootstrap_attr_stack git/attr.c:968:6
#3 0x5651f3413d74 in prepare_attr_stack git/attr.c:1004:2
#4 0x5651f3413d74 in collect_some_attrs git/attr.c:1199:2
#5 0x5651f3413144 in git_check_attr git/attr.c:1345:2
#6 0x5651f34728da in convert_attrs git/convert.c:1320:2
#7 0x5651f3473425 in would_convert_to_git_filter_fd git/convert.c:1373:2
#8 0x5651f357a35e in index_fd git/object-file.c:2630:34
#9 0x5651f357aa15 in index_path git/object-file.c:2657:7
#10 0x5651f35db9d9 in add_to_index git/read-cache.c:766:7
#11 0x5651f35dc170 in add_file_to_index git/read-cache.c:799:9
#12 0x5651f321f9b2 in add_files git/builtin/add.c:346:7
#13 0x5651f321f9b2 in cmd_add git/builtin/add.c:565:18
#14 0x5651f321d327 in run_builtin git/git.c:474:11
#15 0x5651f321bc9e in handle_builtin git/git.c:729:3
#16 0x5651f321a792 in run_argv git/git.c:793:4
#17 0x5651f321a792 in cmd_main git/git.c:928:19
#18 0x5651f33dde1f in main git/common-main.c:62:11
The issue exists because `size` is an output parameter from
`read_blob_data_from_index`, but it's only modified if
`read_blob_data_from_index` returns non-NULL. The read of `size` when
calling `read_attr_from_buf` unconditionally may read from an
uninitialized value. `read_attr_from_buf` checks that `buf` is non-NULL
before reading from `size`, but by then it's already too late: the
uninitialized read will have happened already. Furthermore, there's no
guarantee that the compiler won't reorder things so that it checks
`size` before checking `!buf`.
Make the call to `read_attr_from_buf` conditional on `buf` being
non-NULL, ensuring that `size` is not read if it's never set.
Signed-off-by: Kyle Lippincott <spectral@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitster
pushed a commit
that referenced
this pull request
Aug 19, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitster
pushed a commit
that referenced
this pull request
Aug 22, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitster
pushed a commit
that referenced
this pull request
Aug 23, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitster
added a commit
that referenced
this pull request
Oct 1, 2024
gitster
pushed a commit
that referenced
this pull request
Oct 5, 2024
The incremental MIDX bitmap work was done prior to 9d4855e (midx-write: fix leaking buffer, 2024-09-30), and causes test failures in t5334 in a post-9d4855eef3 world. The leak looks like: Direct leak of 264 byte(s) in 1 object(s) allocated from: #0 0x7f6bcd87eaca in calloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:90 #1 0x55ad1428e8a4 in xcalloc wrapper.c:151 #2 0x55ad14199e16 in prepare_midx_bitmap_git pack-bitmap.c:742 #3 0x55ad14199447 in open_midx_bitmap_1 pack-bitmap.c:507 #4 0x55ad14199cca in open_midx_bitmap pack-bitmap.c:704 #5 0x55ad14199d44 in open_bitmap pack-bitmap.c:717 #6 0x55ad14199dc2 in prepare_bitmap_git pack-bitmap.c:733 #7 0x55ad1419e496 in test_bitmap_walk pack-bitmap.c:2698 #8 0x55ad14047b0b in cmd_rev_list builtin/rev-list.c:629 #9 0x55ad13f71cd6 in run_builtin git.c:487 #10 0x55ad13f72132 in handle_builtin git.c:756 #11 0x55ad13f72380 in run_argv git.c:826 #12 0x55ad13f728f4 in cmd_main git.c:961 #13 0x55ad1407d3ae in main common-main.c:64 #14 0x7f6bcd5f0c89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #15 0x7f6bcd5f0d44 in __libc_start_main_impl ../csu/libc-start.c:360 #16 0x55ad13f6ff90 in _start (git+0x1ef90) (BuildId: 3e63cdd415f1d185b21da3035cb48332510dddce) , and is a result of us not freeing the resources corresponding to the bitmap's base layer, if one was present. Rectify that leak by calling the newly-introduced free_bitmap_index() function on the base layer to ensure that its resources are also freed. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Oct 30, 2024
gitster
pushed a commit
that referenced
this pull request
Nov 5, 2024
This one is a little bit more curious. In t6112, we have a test that
exercises the `git rev-list --filter` option with invalid filters. We
execute git-rev-list(1) via `test_must_fail`, which means that we check
for leaks even though Git exits with an error code. This causes the
following leak:
Direct leak of 27 byte(s) in 1 object(s) allocated from:
#0 0x5555555e6946 in realloc.part.0 lsan_interceptors.cpp.o
#1 0x5555558fb4b6 in xrealloc wrapper.c:137:8
#2 0x5555558b6e06 in strbuf_grow strbuf.c:112:2
#3 0x5555558b7550 in strbuf_add strbuf.c:311:2
#4 0x5555557c1a88 in strbuf_addstr strbuf.h:310:2
#5 0x5555557c1d4c in parse_list_objects_filter list-objects-filter-options.c:261:3
#6 0x555555885ead in handle_revision_pseudo_opt revision.c:2899:3
#7 0x555555884e20 in setup_revisions revision.c:3014:11
#8 0x5555556c4b42 in cmd_rev_list builtin/rev-list.c:588:9
#9 0x5555555ec5e3 in run_builtin git.c:483:11
#10 0x5555555eb1e4 in handle_builtin git.c:749:13
#11 0x5555555ec001 in run_argv git.c:819:4
#12 0x5555555eaf94 in cmd_main git.c:954:19
#13 0x5555556fd569 in main common-main.c:64:11
#14 0x7ffff7ca714d in __libc_start_call_main (.../lib/libc.so.6+0x2a14d)
#15 0x7ffff7ca7208 in __libc_start_main@GLIBC_2.2.5 (.../libc.so.6+0x2a208)
#16 0x5555555ad064 in _start (git+0x59064)
This leak is valid, as we call `die()` and do not clean up the memory at
all. But what's curious is that this is the only leak reported, because
we don't clean up any other allocated memory, either, and I have no idea
why the leak sanitizer treats this buffer specially.
In any case, we can work around the leak by shuffling things around a
bit. Instead of calling `gently_parse_list_objects_filter()` and dying
after we have modified the filter spec, we simply do so beforehand. Like
this we don't allocate the buffer in the error case, which makes the
reported leak go away.
It's not pretty, but it manages to make t6112 leak free.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this adds support for selectively disabling the git bash prompt, which can be useful when managing your home directory with git, for example.