git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] scalar: avoid segfault in reconfigure --all

From
Derrick Stolee <stolee@gmail.com>
Date
May 4, 2024, 13:57 UTC
Message-ID
<0e043864-a5ce-4e21-97eb-15a0bf614fc8@gmail.com>
In-Reply-To
<ZjM23X_Tf3pcWsIq@tanuki>
On 5/2/24 2:46 AM, Patrick Steinhardt wrote:
Show 20 quoted lines
> On Tue, Apr 30, 2024 at 04:58:52PM +0000, Derrick Stolee via GitGitGadget wrote:
>> From: Derrick Stolee <stolee@gmail.com>
>>
>> During the latest v2.45.0 update, 'scalar reconfigure --all' started to
>> segfault on my machine. Breaking it down via the debugger, it was
>> faulting on a NULL reference to the_hash_algo, which is a macro pointing
>> to the_repository->hash_algo.
>>
>> This NULL reference appears to be due to the way the loop is abusing the
>> the_repository pointer, pointing it to a local repository struct after
>> discovering that the current directory is a valid Git repository. This
>> repo-swapping bit was in the original implementation from 4582676075
>> (scalar: teach 'reconfigure' to optionally handle all registered
>> enlistments, 2021-12-03), but only recently started segfaulting while
>> trying to parse the HEAD reference. This also only happens on the
>> _second_ repository in the list, so does not reproduce if there is only
>> one registered repo.
> Interesting. This also has some overlap with my patch series that aims
> to drop the default-SHA1 fallback that we have in place for
> `the_repository` [1].
Thanks for this pointer. It indeed will help.
Show 11 quoted lines
>> Add a test to t9210-scalar.sh to test 'scalar reconfigure --all' with
>> multiple registered repos, as a precaution. Unfortunately, I was unable
>> to reproduce the segfault using this test, so there is some coverage
>> left to be desired. What exactly causes my setup to hit this bug but not
>> this test structure? Unclear.
> One way to trigger _a_ BUG is to use an "includeIf.onbranch:foobar.path"
> config. This will cause Git to try and look up the "HEAD" reference, but
> because we have a partially-configured repository, only, that will crash
> with:
>
>      BUG: refs.c:2123: reference backend is unknown
This is a good extra find. After your explanation for the second
test, I'm confident that I was hitting the detached HEAD case on
my machine.
I will shamelessly steal your tests in my v2.
Show 5 quoted lines
> This issue should be fixed by my patch series in [1] because we start to
> use `get_oid_hex_any()` to parse detached HEADs.
>
> Anyway, your fix is indeed effective because with `repo_init()` we now
> properly configure the repository.
I appreciate that your series will fix this in a ref-focused way. I think
this change could prevent other bad interactions with the_repository in
the future.
Thanks,
-Stolee
Previous: Patrick SteinhardtNext: Derrick Stolee via GitGitGadget
Message 3 of 7 in “scalar: avoid segfault in reconfigure --all”
  1. scalar: avoid segfault in reconfigure --allDerrick Stolee via GitGitGadget, Apr 30, 2024
  2. Patrick SteinhardtMay 2, 2024
  3. Derrick StoleeMay 4, 2024
  4. scalar: avoid segfault in reconfigure --allDerrick Stolee via GitGitGadget, May 5, 2024
  5. Patrick SteinhardtMay 6, 2024
  6. scalar: avoid segfault in reconfigure --allDerrick Stolee via GitGitGadget, May 8, 2024
  7. Patrick SteinhardtMay 8, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.