threads / bug / 55118

BUG: commit-reach.c:66: bad generation skip

Subject: BUG: commit-reach.c:66: bad generation skip

## tl;dr

6 messages between Feb 7, 2021 and Feb 10, 2021.

replies: 5people: 3as markdown or json

Filippo Valsorda· Feb 7, 2021, 22:28 UTC · lore
What did you do before the bug happened? (Steps to reproduce your issue)
$ git merge origin/master
What happened instead? (Actual behavior)
BUG: commit-reach.c:66: bad generation skip     ad18 >        7 at
be28e5abc5ddca0d6b2d8c91b7bb9c05717154e7
Anything else you want to add:

Running in a worktree of a clone of https://go.googlesource.com/go. HEAD is 0d34d85dee216b62a4212d25de57e1119c1e7ee5, branch is filippo/boringcrypto/16, tracking and matching origin/dev.boringcrypto. origin/master is 724d0720b3e110f64598bf789cbe2a6a1b3b0fd8.

[System Info] git version: git version 2.30.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Mon Dec 7 22:04:02 PST 2020; root:xnu-7195.80.16.111.1~1/RELEASE_X86_64 x86_64 compiler info: clang: 12.0.0 (clang-1200.0.32.28) libc info: no libc information available $SHELL (typically, interactive shell): /Users/valsorda/homebrew/bin/zsh

[Enabled Hooks] pre-commit commit-msg

Filippo Valsorda· Feb 7, 2021, 22:31 UTC · re: Filippo Valsorda · lore

Re: BUG: commit-reach.c:66: bad generation skip

I was able to workaround this bug with a "git gc" invocation.
On Sun, Feb 7, 2021 at 11:28 PM Filippo Valsorda <valsorda@google.com> wrote:
Show 39 quoted lines
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> $ git merge origin/master
>
>
> What happened instead? (Actual behavior)
>
> BUG: commit-reach.c:66: bad generation skip     ad18 >        7 at
> be28e5abc5ddca0d6b2d8c91b7bb9c05717154e7
>
>
> Anything else you want to add:
>
> Running in a worktree of a clone of https://go.googlesource.com/go.
> HEAD is 0d34d85dee216b62a4212d25de57e1119c1e7ee5, branch is
> filippo/boringcrypto/16,
> tracking and matching origin/dev.boringcrypto.
> origin/master is 724d0720b3e110f64598bf789cbe2a6a1b3b0fd8.
>
>
> [System Info]
> git version:
> git version 2.30.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Mon Dec  7 22:04:02
> PST 2020; root:xnu-7195.80.16.111.1~1/RELEASE_X86_64 x86_64
> compiler info: clang: 12.0.0 (clang-1200.0.32.28)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /Users/valsorda/homebrew/bin/zsh
>
>
> [Enabled Hooks]
> pre-commit
> commit-msg
Derrick Stolee· Feb 8, 2021, 02:26 UTC · re: Filippo Valsorda · lore

Re: BUG: commit-reach.c:66: bad generation skip

On 2/7/2021 5:31 PM, Filippo Valsorda wrote:
> 
> On Sun, Feb 7, 2021 at 11:28 PM Filippo Valsorda <valsorda@google.com> wrote:
>> [System Info]
>> git version:
>> git version 2.30.0

_This_ is interesting. I haven't heard of this problem happening in a released version of Git.

I'm CC'ing Jonathan Nieder who recently saw this happening, but that was on a newer version than 2.30.0 with a topic that is not part of 2.30.0. But maybe the version shipped internally is versioned without extra information on top of the latest tag? (I see your @google.com email, which makes me think you have an internal version.)

>> What happened instead? (Actual behavior)
>>
>> BUG: commit-reach.c:66: bad generation skip     ad18 >        7 at
>> be28e5abc5ddca0d6b2d8c91b7bb9c05717154e7

This was recently reported, but it was thought to be due to an in-process topic branch. If you recently had that version installed, then your data would have needed a rewrite anyway.

This hints towards more problems with generation numbers across split commit-graph layers. (The child has generation number 7, so it is likely part of a thin layer.)

This might be sufficient evidence to convert this BUG() to a warning with something like:

  warning: The commit-graph file has incorrect reachability index
  warning: information. Results may be incorrect until commit-graph
  warning: is rewritten with 'git commit-graph write'.

This could also be a die() instead of warning(), as that command itself might return incorrect results.

> I was able to workaround this bug with a "git gc" invocation.

Yes, this will delete (and possibly replace) your commit-graph file where the bad data lies.

To better understand your situation, could you please run the following commands?

	git config --get-regexp graph
	git config features.experimental

I'm specifically looking for values of fetch.writeCommitGraph and gc.writeCommitGraph.

Thanks, -Stolee

Filippo Valsorda· Feb 10, 2021, 12:18 UTC · re: Derrick Stolee · lore

Re: BUG: commit-reach.c:66: bad generation skip

On Mon, Feb 8, 2021 at 3:26 AM Derrick Stolee <stolee@gmail.com> wrote:
Show 8 quoted lines
> _This_ is interesting. I haven't heard of this problem happening
> in a released version of Git.
>
> I'm CC'ing Jonathan Nieder who recently saw this happening, but that
> was on a newer version than 2.30.0 with a topic that is not part
> of 2.30.0. But maybe the version shipped internally is versioned
> without extra information on top of the latest tag? (I see your
> @google.com email, which makes me think you have an internal version.)

Ah, the issue indeed first showed up as I was using the internal version. I then installed mainline 2.30.0 to check that it reproduced on the same local repository before reporting a bug.

Show 8 quoted lines
> To better understand your situation, could you please run the
> following commands?
>
>         git config --get-regexp graph
>         git config features.experimental
>
> I'm specifically looking for values of fetch.writeCommitGraph and
> gc.writeCommitGraph.
fetch.writecommitgraph is enabled on the internal version.

$ git version git version 2.30.0.478.g8a0d178c01-goog $ git config --get-regexp graph fetch.writecommitgraph true $ git config features.experimental $ ~/homebrew/bin/git version git version 2.30.0 $ ~/homebrew/bin/git config --get-regexp graph $ ~/homebrew/bin/git config features.experimental

I zipped up the repository and the worktree before running gc, so I can run other commands for you if you need, but unfortunately I can't share the archive, as it fetched from a private branch with security fixes.

Derrick Stolee· Feb 10, 2021, 12:24 UTC · re: Filippo Valsorda · lore

Re: BUG: commit-reach.c:66: bad generation skip

On 2/10/2021 7:18 AM, Filippo Valsorda wrote:
Show 13 quoted lines
> On Mon, Feb 8, 2021 at 3:26 AM Derrick Stolee <stolee@gmail.com> wrote:
>> _This_ is interesting. I haven't heard of this problem happening
>> in a released version of Git.
>>
>> I'm CC'ing Jonathan Nieder who recently saw this happening, but that
>> was on a newer version than 2.30.0 with a topic that is not part
>> of 2.30.0. But maybe the version shipped internally is versioned
>> without extra information on top of the latest tag? (I see your
>> @google.com email, which makes me think you have an internal version.)
> 
> Ah, the issue indeed first showed up as I was using the internal
> version. I then installed mainline 2.30.0 to check that it reproduced
> on the same local repository before reporting a bug.

The mainline does have the BUG() statement, but it's really reflecting bad data in the commit-graph file. That data was written by the internal version and was not reset until you rewrote the file.

Show 24 quoted lines
>> To better understand your situation, could you please run the
>> following commands?
>>
>>         git config --get-regexp graph
>>         git config features.experimental
>>
>> I'm specifically looking for values of fetch.writeCommitGraph and
>> gc.writeCommitGraph.
> 
> fetch.writecommitgraph is enabled on the internal version.
> 
> $ git version
> git version 2.30.0.478.g8a0d178c01-goog
> $ git config --get-regexp graph
> fetch.writecommitgraph true
> $ git config features.experimental
> $ ~/homebrew/bin/git version
> git version 2.30.0
> $ ~/homebrew/bin/git config --get-regexp graph
> $ ~/homebrew/bin/git config features.experimental
> 
> I zipped up the repository and the worktree before running gc, so I can
> run other commands for you if you need, but unfortunately I can't share
> the archive, as it fetched from a private branch with security fixes.

Thanks, but let me know if it reproduces again. The bug should be fixed in ds/commit-graph-genno-fix [1], and I think the Google internal release has been rolled back until that branch is included.

[1] https://github.com/gitster/git/commits/ds/commit-graph-genno-fix

Thanks, -Stolee

Junio C Hamano· Feb 10, 2021, 20:14 UTC · re: Derrick Stolee · lore

Re: BUG: commit-reach.c:66: bad generation skip

Derrick Stolee <stolee@gmail.com> writes:
Show 18 quoted lines
> On 2/10/2021 7:18 AM, Filippo Valsorda wrote:
>> On Mon, Feb 8, 2021 at 3:26 AM Derrick Stolee <stolee@gmail.com> wrote:
>>> _This_ is interesting. I haven't heard of this problem happening
>>> in a released version of Git.
>>>
>>> I'm CC'ing Jonathan Nieder who recently saw this happening, but that
>>> was on a newer version than 2.30.0 with a topic that is not part
>>> of 2.30.0. But maybe the version shipped internally is versioned
>>> without extra information on top of the latest tag? (I see your
>>> @google.com email, which makes me think you have an internal version.)
>> 
>> Ah, the issue indeed first showed up as I was using the internal
>> version. I then installed mainline 2.30.0 to check that it reproduced
>> on the same local repository before reporting a bug.
>
> The mainline does have the BUG() statement, but it's really reflecting
> bad data in the commit-graph file. That data was written by the internal
> version and was not reset until you rewrote the file.

Thanks for digging, you two. The above clearly explains the symptom.

> Thanks, but let me know if it reproduces again. The bug should be fixed
> in ds/commit-graph-genno-fix [1], and I think the Google internal release
> has been rolled back until that branch is included.

The topic has been cooking in 'next' since Feb 3rd, so jrnieder's team would probably have already picked it up. It would be in 'master', together with the ak/corrected-commit-date topic it builds on, not in a very distant future (typically a topic cooks in 'next' for a week, unless it is a trivial typofix, doc updates, that sort of low-impact change).

Thanks.

← back to recent threads