summaryrefslogtreecommitdiffstats
path: root/sh-i18n--envsubst.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-09-30revision: fix memory leaks when rewriting parentsPatrick Steinhardt6-0/+7
Both `rewrite_parents()` and `remove_duplicate_parents()` may end up dropping some parents from a commit without freeing the respective `struct commit_list` items. This causes a bunch of memory leaks. Plug these. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30midx-write: fix leaking bufferPatrick Steinhardt2-0/+4
The buffer used to compute the final MIDX name is never released. Plug this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30pack-bitmap-write: fix leaking OID arrayPatrick Steinhardt2-0/+2
Fix a leaking OID array in `write_pseudo_merges()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30pseudo-merge: fix leaking strmap keysPatrick Steinhardt1-2/+2
When creating a new pseudo-merge group we collect a set of matchnig commits and put them into a string map. This strmap is initialized such that it does not allocate its keys, and instead we try to pass ownership of the keys to it via `strmap_put()`. This isn't how it works though: the strmap will never try to release these keys, and consequently they end up leaking. Fix this leak by initializing the strmap as duplicating its keys and not trying to hand over ownership. The leak is exposed by t5333, but plugging it does not yet make the full test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30pseudo-merge: fix various memory leaksPatrick Steinhardt4-2/+31
Fix various memory leaks hit by the pseudo-merge machinery. These leaks are exposed by t5333, but plugging them does not yet make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30line-log: fix several memory leaksPatrick Steinhardt1-19/+35
As described in "line-log.c" itself, the code is "leaking like a sieve". These leaks are all of rather trivial nature, so this commit plugs them without going too much into details for each of those leaks. The leaks are hit by t4211, but plugging them alone does not make the full test suite pass. The remaining leaks are unrelated to the line-log subsystem. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30diff: improve lifecycle management of diff queuesPatrick Steinhardt10-47/+32
The lifecycle management of diff queues is somewhat confusing: - For most of the part this can be attributed to `DIFF_QUEUE_CLEAR()`, which does not release any memory but rather initializes the queue, only. This is in contrast to our common naming schema, where "clearing" means that we release underlying memory and then re-initialize the data structure such that it is ready to use. - A second offender is `diff_free_queue()`, which does not free the queue structure itself. It is rather a release-style function. Refactor the code to make things less confusing. `DIFF_QUEUE_CLEAR()` is replaced by `DIFF_QUEUE_INIT` and `diff_queue_init()`, while `diff_free_queue()` is replaced by `diff_queue_release()`. While on it, adapt callsites where we call `DIFF_QUEUE_CLEAR()` with the intent to release underlying memory to instead call `diff_queue_clear()` to fix memory leaks. This memory leak is exposed by t4211, but plugging it alone does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30builtin/revert: fix leaking `gpg_sign` and `strategy` configPatrick Steinhardt2-4/+14
We leak the config values when `gpg_sign` or `strategy` options are being overridden via the command line. To fix this we need to free the old value, which requires us to figure out whether the value was changed via an option in the first place. The easy way to do this, which is to initialize local variables with `NULL`, doesn't work because we cannot tell the case where the user has passed e.g. `--no-gpg-sign`. Instead, we use a sentinel value for both values that we can compare against to check whether the user has passed the option. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30t/helper: fix leaking repository in partial-clone helperPatrick Steinhardt2-0/+3
We initialize but never clear a repository in the partial-clone test helper. Plug this leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30builtin/clone: fix leaking repo state when cloning with bundle URIsPatrick Steinhardt4-0/+30
When cloning with bundle URIs we re-initialize `the_repository` after having fetched the bundle. This causes a bunch of memory leaks though because we do not release its previous state. These leaks can be plugged by calling `repo_clear()` before we call `repo_init()`. But this causes another issue because the remote that we used is tied to the lifetime of the repository's remote state, which would also get released. We thus have to make sure that it does not get free'd under our feet. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30builtin/pack-redundant: fix various memory leaksPatrick Steinhardt2-6/+35
There are various different memory leaks in git-pack-redundant(1), mostly caused by not even trying to free allocated memory. Fix them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30builtin/stash: fix leaking `pathspec_from_file`Patrick Steinhardt2-1/+4
The `OPT_PATHSPEC_FROM_FILE()` option maps to `OPT_FILENAME()`, which we know will always allocate memory when passed. We never free the memory though, causing a memory leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30submodule: fix leaking submodule entry listPatrick Steinhardt4-3/+24
The submodule entry list returned by `submodules_of_tree()` is never completely free'd by its only caller. Introduce a new function that free's the list for us and call it. While at it, also fix the leaking `branch_point` string. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30wt-status: fix leaking buffer with sparse directoriesPatrick Steinhardt2-1/+6
When hitting a sparse directory in `wt_status_collect_changes_initial()` we use a `struct strbuf` to assemble the directory's name. We never free that buffer though, causing a memory leak. Fix the leak by releasing the buffer. While at it, move the buffer outside of the loop and reset it to save on some wasteful allocations. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30shell: fix leaking stringsPatrick Steinhardt3-3/+6
There are two memory leaks in "shell.c". The first one in `run_shell()` is trivial and fixed without further explanation. The second one in `cmd_main()` happens because we overwrite the `prog` variable, which contains an allocated string. In fact though, the memory pointed to by that variable is still in use because we use `split_cmdline()`, which may create pointers into the middle of that string. But as we do not have a direct pointer to the head of the allocated string anymore, we get a complaint by the leak checker. Address this by not overwriting the `prog` pointer. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30scalar: fix leaking repositoriesPatrick Steinhardt3-0/+3
In the scalar code we iterate through multiple repositories, initializing each of them. We never clear them though, causing memory leaks. Plug them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30read-cache: fix leaking hash context in `do_write_index()`Patrick Steinhardt1-0/+1
When writing an index with the EOIE extension we allocate a separate hash context. We never free that context though, causing a memory leak. Plug it. This leak is exposed by t9210, but plugging it alone does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-30builtin/annotate: fix leaking args vectorPatrick Steinhardt2-5/+16
We're leaking the args vector in git-annotate(1) because we never clear it. Fixing it isn't as easy as calling `strvec_clear()` though because calling `cmd_blame()` will cause the underlying array to be modified. Instead, we also need to pass a shallow copy of the argv array to the function. Do so to plug the memory leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27diffcore-break: fix leaking filespecs when merging broken pairsPatrick Steinhardt6-2/+9
When merging file pairs after they have been broken up we queue a new file pair and discard the broken-up ones. The newly-queued file pair reuses one filespec of the broken up pairs each, where the respective other filespec gets discarded. But we only end up freeing the filespec's data, not the filespec itself, and thus leak memory. Fix these leaks by using `free_filespec()` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27revision: fix leaking parents when simplifying commitsPatrick Steinhardt7-0/+12
When simplifying commits, e.g. because they are treesame with their parents, we unset the commit's parent pointers but never free them. Plug the resulting memory leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/maintenance: fix leak in `get_schedule_cmd()`Patrick Steinhardt2-47/+81
The `get_schedule_cmd()` function allows us to override the schedule command with a specific test command such that we can verify the underlying logic in a platform-independent way. Its memory management is somewhat wild though, because it basically gives up and assigns an allocated string to the string constant output pointer. While this part is marked with `UNLEAK()` to mask this, we also leak the local string lists. Rework the function such that it has a separate out parameter. If set, we will assign it the final allocated command. Plug the other memory leaks and create a common exit path. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/maintenance: fix leaking config stringPatrick Steinhardt1-2/+2
When parsing the maintenance strategy from config we allocate a config string, but do not free it after parsing it. Plug this leak by instead using `git_config_get_string_tmp()`, which does not allocate any memory. This leak is exposed by t7900, but plugging it alone does not make the test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27promisor-remote: fix leaking partial clone filterPatrick Steinhardt2-0/+3
The partial clone filter of a promisor remote is never free'd, causing memory leaks. Furthermore, in case multiple partial clone filters are defined for the same remote, we'd overwrite previous values without freeing them. Fix these leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27grep: fix leaking grep patternPatrick Steinhardt1-1/+1
When creating a pattern via `create_grep_pat()` we allocate the pattern member of the structure regardless of the token type. But later, when we try to free the structure, we free the pattern member conditionally on the token type and thus leak memory. Plug this leak. The leak is exposed by t7814, but plugging it alone does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27submodule: fix leaking submodule ODB pathsPatrick Steinhardt1-2/+2
In `add_submodule_odb_by_path()` we add a path into a global string list. The list is initialized with `NODUP`, which means that we do not pass ownership of strings to the list. But we use `xstrdup()` when we insert a path, with the consequence that the string will never get free'd. Plug the leak by marking the list as `DUP`. There is only a single callsite where we insert paths anyway, and as explained above that callsite was mishandling the allocation. This leak is exposed by t7814, but plugging it does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27trace2: destroy context stored in thread-local storagePatrick Steinhardt1-1/+9
Each thread may have a specific context in the trace2 subsystem that we set up via thread-local storage. We do not set up a destructor for this data though, which means that the context data will leak. Plug this leak by installing a destructor. This leak is exposed by t7814, but plugging it alone does not make the whole test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/difftool: plug several trivial memory leaksPatrick Steinhardt2-0/+7
There are several leaking data structures in git-difftool(1). Plug them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/repack: fix leaking configurationPatrick Steinhardt3-15/+45
When repacking, we assemble git-pack-objects(1) arguments both for the "normal" pack and for the cruft pack. This configuration gets populated with a bunch of `OPT_PASSTHRU` options that we end up passing to the child process. These options are allocated, but never free'd. Create a new `pack_objects_args_release()` function that releases the memory for us and call it for both sets of options. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27diffcore-order: fix leaking buffer when parsing orderfilesPatrick Steinhardt3-12/+9
In `prepare_order()` we parse an orderfile and assign it to a global array. In order to save on some allocations, we replace newlines with NUL characters and then assign pointers into the allocated buffer to that array. This can cause the buffer to be completely unreferenced though in some cases, e.g. because the order file is empty or because we had to use `xmemdupz()` to copy the lines instead of NUL-terminating them. Refactor the code to always `xmemdupz()` the strings. This is a bit simpler, and it is rather unlikely that saving a handful of allocations really matters. This allows us to release the string buffer and thus plug the memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27parse-options: free previous value of `OPTION_FILENAME`Patrick Steinhardt1-8/+14
The `OPTION_FILENAME` option always assigns either an allocated string or `NULL` to the value. In case it is passed multiple times it does not know to free the previous value though, which causes a memory leak. Refactor the function to always free the previous value. None of the sites where this option is used pass a string constant, so this change is safe. While at it, fix the argument of `fix_filename()` to be a string constant. The only reason why it's not is because we use it as an in-out-parameter, where the input is a constant and the output is not. This is weird and unnecessary, as we can just return the result instead of using the parameter for this. This leak is being hit in t7621, but plugging it alone does not make the test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27diff: fix leaking orderfile optionPatrick Steinhardt3-5/+7
The `orderfile` diff option is being assigned via `OPT_FILENAME()`, which assigns an allocated string to the variable. We never free it though, causing a memory leak. Change the type of the string to `char *` and free it to plug the leak. This also requires us to use `xstrdup()` to assign the global config to it in case it is set. This leak is being hit in t7621, but plugging it alone does not make the test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/pull: fix leaking "ff" optionPatrick Steinhardt2-4/+8
The `opt_ff` field gets populated either via `OPT_PASSTHRU` via `config_get_ff()` or when `--rebase` is passed. So we sometimes end up overriding the value in `opt_ff` with another value, but we do not free the old value, causing a memory leak. Adapt the type of the variable to be `char *` and consistently assign allocated strings to it such that we can easily free it when it is being overridden. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27dir: fix off by one errors for ignored and untracked entriesPatrick Steinhardt4-4/+5
In `treat_directory()` we perform some logic to handle ignored and untracked entries. When populating a directory with entries we first save the current number of ignored/untracked entries and then populate new entries at the end of our arrays that keep track of those entries. When we figure out that all entries have been ignored/are untracked we then remove this tail of entries from those vectors again. But there is an off by one error in both paths that causes us to not free the first ignored and untracked entries, respectively. Fix these off-by-one errors to plug the resulting leak. While at it, massage the code a bit to match our modern code style. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/submodule--helper: fix leaking remote ref on errorsPatrick Steinhardt2-4/+10
When `update_submodule()` fails we return with `die_message()`, which only causes us to print the same message as `die()` would without actually causing the process to die. We don't free memory in that case and thus leak memory. Fix the leak by freeing the remote ref. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27t/helper: fix leaking subrepo in nested submodule config helperPatrick Steinhardt2-1/+2
In the "submodule-nested-repo-config" helper we create a submodule repository and print its configuration. We do not clear the repo, causing a memory leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/submodule--helper: fix leaking error bufferPatrick Steinhardt2-0/+4
Fix leaking error buffer when `compute_alternate_path()` fails. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/submodule--helper: clear child process when not running itPatrick Steinhardt2-3/+8
In `runcommand_in_submodule_cb()` we may end up not executing the child command when `argv` is empty. But we still populate the command with environment variables and other things, which needs cleanup. This leads to a memory leak because we do not call `finish_command()`. Fix this by clearing the child process when we don't execute it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27submodule: fix leaking update strategyPatrick Steinhardt5-3/+12
We're not freeing the submodule update strategy command. Provide a helper function that does this for us and call it in `update_data_release()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27git: fix leaking argv when handling builtinsPatrick Steinhardt2-3/+20
In `handle_builtin()` we may end up creating an ad-hoc argv array in case we see that the command line contains the "--help" parameter. In this case we observe two memory leaks though: - We leak the `struct strvec` itself because we directly exit after calling `run_builtin()`, without bothering about any cleanups. - Even if we free'd that vector we'd end up leaking some of its strings because `run_builtin()` will modify the array. Plug both of these leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/help: fix leaking `html_path` when reading config multiple timesPatrick Steinhardt1-1/+2
The `html_path` variable gets populated via `git_help_config()`, which puts an allocated string into it if its value has been configured. We do not clear the old value though, which causes a memory leak in case the config exists multiple times. Plug this leak. The leak is exposed by t0012, but plugging it alone is not sufficient to make the test suite pass. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-27builtin/help: fix dangling reference to `html_path`Patrick Steinhardt1-6/+7
In `get_html_page_path()` we may end up assigning the return value of `system_path()` to the global `html_path` variable. But as we also assign the returned value to `to_free`, we will deallocate its memory upon returning from the function. Consequently, `html_path` will now point to deallocated memory. Fix this issue by instead assigning the value to a separate local variable. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-26Git 2.47-rc0v2.47.0-rc0Junio C Hamano2-1/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25The 21st batchJunio C Hamano1-0/+9
This pretty much should match what we would have in the upcoming preview of 2.47. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: clean up local_refs at exitJeff King2-1/+3
We allocate a list of ref structs from get_local_heads() but never clean it up. We should do so before exiting to avoid complaints from the leak-checker. Note that we have to initialize it to NULL, because there's one code path that can jump to the cleanup label before we assign to it. Fixing this lets us mark t5540 as leak-free. Curiously building with SANITIZE=leak and gcc does not seem to find this problem, but switching to clang does. It seems like a fairly obvious leak, though. I was curious that the matching remote_refs did not have the same leak. But that is because we store the list in a global variable, so it's still reachable after we exit. Arguably we could treat it the same as future-proofing, but I didn't bother (now that the script is marked leak-free, anybody moving it to a stack variable will notice). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: clean up loose request when falling back to packedJeff King1-1/+2
In http-push's finish_request(), if we fail a loose object request we may fall back to trying a packed request. But if we do so, we leave the http_loose_object_request in place, leaking it. We can fix this by always cleaning it up. Note that the obj_req pointer here (which we'll set to NULL) is a copy of the request->userData pointer, which will now point to freed memory. But that's OK. We'll either release the parent request struct entirely, or we'll convert it into a packed request, which will overwrite userData itself. This leak is found by t5540, but it's not quite leak-free yet. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: clean up objects listJeff King1-1/+5
In http-push's get_delta(), we generate a list of pending objects by recursively processing trees and blobs, adding them to a linked list. And then we iterate over the list, adding a new request for each element. But since we iterate using the list head pointer, at the end it is NULL and all of the actual list structs have been leaked. We can fix this either by using a separate iterator and then calling object_list_free(), or by just freeing as we go. I picked the latter, just because it means we continue to shrink the list as we go, though I'm not sure it matters in practice (we call add_send_request() in the loop, but I don't think it ever looks at the global objects list itself). This fixes several leaks noticed in t5540. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: free xml_ctx.cdata after useJeff King1-0/+2
When we ask libexpat to parse XML data, we sometimes set xml_cdata as a CharacterDataHandler callback. This fills in an allocated string in the xml_ctx struct which we never free, causing a leak. I won't pretend to understand the purpose of the field, but it looks like it is used by other callbacks during the parse. At any rate, we never look at it again after XML_Parse() returns, so we should be OK to free() it then. This fixes several leaks triggered by t5540. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: free remote_ls_ctx.dentry_nameJeff King1-0/+1
The remote_ls_ctx struct has dentry_name string, which is filled in with a heap allocation in the handle_remote_ls_ctx() XML callback. After the XML parse is done in remote_ls(), we should free the string to avoid a leak. This fixes several leaks found by running t5540. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: free transfer_request strbufJeff King1-1/+4
When we issue a PUT, we initialize and fill a strbuf embedded in the transfer_request struct. But we never release this buffer, causing a leak. We can fix this by adding a strbuf_release() call to release_request(). If we stopped there, then non-PUT requests would try to release a zero-initialized strbuf. This works OK in practice, but we should try to follow the strbuf API more closely. So instead, we'll always initialize the strbuf when we create the transfer_request struct. That in turn means switching the strbuf_init() call in start_put() to a simple strbuf_grow(). This leak is triggered in t5540. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-25http-push: free transfer_request dest fieldJeff King1-7/+3
When we issue a PUT request, we store the destination in the "dest" field by detaching from a strbuf. But we never free the result, causing a leak. We can address this in the release_request() function. But note that we also need to initialize it to NULL, as most other request types do not set it at all. Curiously there are _two_ functions to initialize a transfer_request struct. Adding the initialization only to add_fetch_request() seems to be enough for t5540, but I won't pretend to understand why. Rather than just adding "request->dest = NULL" in both spots, let's zero the whole struct. That addresses this problem, as well as any future ones (and it can't possibly hurt, as by definition we'd be hitting uninitialized memory previously). This fixes several leaks noticed by t5540. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>