segfault with git rebase --abort

segfault with git rebase --abort

[Wolfgang Rohdewald]

git rebase -i

git rebase --abort # boom

git status only shows changes to be committed
I can mail or upload the git archive, that would be 230MB

git fsck;git repack;git prune;git gc does not help

Happens with git 2.39 and with latest git commit 11c821f2f2a31e70fb5cc449f9a29401c333aad2, compiled with -g -O0

gdb:

Starting program: /home/wr/bin/git rebase --abort
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00005555557ef89a in has_rerere_resolution (id=0x5555559f5950) at rerere.c:167
167             return ((id->collection->status[variant] & both) == both);
(gdb) bt
#0  0x00005555557ef89a in has_rerere_resolution (id=0x5555559f5950) at rerere.c:167
#1  0x00005555557f249c in rerere_clear (r=0x5555559ea220 <the_repo>, merge_rr=0x7fffffffc0a0) at rerere.c:1249
#2  0x000055555562388e in cmd_rebase (argc=0, argv=0x7fffffffd8b0, prefix=0x0) at builtin/rebase.c:1315
#3  0x0000555555574b71 in run_builtin (p=0x5555559b6010 <commands+2256>, argc=2, argv=0x7fffffffd8b0) at git.c:469
#4  0x0000555555574f8c in handle_builtin (argc=2, argv=0x7fffffffd8b0) at git.c:724
#5  0x00005555555751b0 in run_argv (argcp=0x7fffffffd71c, argv=0x7fffffffd710) at git.c:788
#6  0x0000555555575724 in cmd_main (argc=2, argv=0x7fffffffd8b0) at git.c:923
#7  0x0000555555673c7a in main (argc=3, argv=0x7fffffffd8a8) at common-main.c:62
(gdb) p id->collection->status
$2 = (unsigned char *) 0x0
(gdb) p *(id->collection)
$3 = {status_alloc = 0, status_nr = 0, status = 0x0, name = 0x5555559f5e80 "a8ec6f624ee23ef2e37148a8172ebac3c6639f93"}

there is no file named a8ec6f624ee23ef2e37148a8172ebac3c6639f93


[System Info]
git version:
git version 2.44.GIT
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.6.22-25 #1 SMP PREEMPT_DYNAMIC Sun Mar 17 12:35:12 CET 2024 x86_64
compiler info: gnuc: 12.2
libc info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

-- 
mit freundlichen Grüssen

Wolfgang Rohdewald

Re: segfault with git rebase --abort

[Junio C Hamano]

Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:

> git rebase -i
>
> git rebase --abort # boom
>
> git status only shows changes to be committed
> I can mail or upload the git archive, that would be 230MB
>
> git fsck;git repack;git prune;git gc does not help

This thread _might_ be relevant.

  https://lore.kernel.org/git/20240218114936.1121077-1-marcel@roethke.info/

The "might" is because the symptom is a sign of corruption of the
rerere database but the discussion or the patch in there do not know
how such a corruption happened in the first place.

If you rebuild Git with Marcel's patch (there is v2 downthread, and
we have been waiting for a v3) and it improves the situation, please
do let us know.

Thanks.

Re: segfault with git rebase --abort

[Wolfgang Rohdewald]

Am Sonntag, dem 24.03.2024 um 14:54 -0700 schrieb Junio C Hamano:
> Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:
> 
> > git rebase -i
> > 
> > git rebase --abort # boom
> > 
> This thread _might_ be relevant.
> 
>   https://lore.kernel.org/git/20240218114936.1121077-1-marcel@roethke.info/
> 
> The "might" is because the symptom is a sign of corruption of the
> rerere database but the discussion or the patch in there do not know
> how such a corruption happened in the first place.
> 
> If you rebuild Git with Marcel's patch (there is v2 downthread, and
> we have been waiting for a v3) and it improves the situation, please
> do let us know.

Yes, the patch resolved my problem. Thanks a lot!

From the bash history below, this might be the sequence:

(git 2.39)

I think I forgot to remove one line of "<<<<<<< HEAD" before doing the first git add.

Because git rebase --abort then told me about the lockfile, the segfault probably
already happened with the second git rebase --continue.
and from then on all git rebase --abort segfaulted.

Oh - and I definitively did not mess around in .git

I do have a backup of the repo, so if you want me to look up things ...

git checkout master
git rebase -i
vi servertable.py
git add servertable.py  # here I probably left that <<<< HEAD line
git rebase --continue
vi servertable.py 
git add servertable.py
git rebase --continue   # I think this already segfaulted
git status
df                      # plenty of free space
git rebase --abort
rm .git/MERGE_RR.lock


Since the patch is about rerere, I now did:

wrpc:~/tmp/kajongg (master|REBASE-i) git rerere status
src/servertable.py
wrpc:~/tmp/kajongg (master|REBASE-i) git rerere diff
error: Could not stat .git/rr-cache/a8ec6f624ee23ef2e37148a8172ebac3c6639f93/preimage: No such file or directory
fatal: unable to generate diff for '.git/rr-cache/a8ec6f624ee23ef2e37148a8172ebac3c6639f93'

wrpc:~/tmp/kajongg/.git/rr-cache (GIT_DIR!|REBASE-i) ls -lrt | tail -3
drwxr-xr-x 2 wr wr 4096 Mar 24 16:19 e6c7ce944f313fa718cad6875d4ee784c098868c
drwxr-xr-x 2 wr wr 4096 Mar 24 16:19 d0a20608fa0aafd2b234cce432ce7af567c1a94a
drwxr-xr-x 2 wr wr 4096 Mar 24 16:43 a8ec6f624ee23ef2e37148a8172ebac3c6639f93
wrpc:~/tmp/kajongg/.git/rr-cache (GIT_DIR!|REBASE-i) ls -l a8ec6f624ee23ef2e37148a8172ebac3c6639f93/
total 0


-- 
mit freundlichen Grüssen

Wolfgang Rohdewald

Re: segfault with git rebase --abort

[Junio C Hamano]

Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:

> Am Sonntag, dem 24.03.2024 um 14:54 -0700 schrieb Junio C Hamano:
>> Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:
>> 
>> > git rebase -i
>> > 
>> > git rebase --abort # boom
>> > 
>> This thread _might_ be relevant.
>> 
>>  https://lore.kernel.org/git/20240218114936.1121077-1-marcel@roethke.info/
>> 
>> The "might" is because the symptom is a sign of corruption of the
>> rerere database but the discussion or the patch in there do not know
>> how such a corruption happened in the first place.
>> 
>> If you rebuild Git with Marcel's patch (there is v2 downthread, and
>> we have been waiting for a v3) and it improves the situation, please
>> do let us know.
>
> Yes, the patch resolved my problem. Thanks a lot!

Thanks for testing (and thanks, Marcel, for writing a fix).

>
> From the bash history below, this might be the sequence:
>
> (git 2.39)
>
> I think I forgot to remove one line of "<<<<<<< HEAD" before doing the first git add.
>
> Because git rebase --abort then told me about the lockfile, the segfault probably
> already happened with the second git rebase --continue.
> and from then on all git rebase --abort segfaulted.
>
> Oh - and I definitively did not mess around in .git
>
> I do have a backup of the repo, so if you want me to look up things ...
>
> git checkout master
> git rebase -i
> vi servertable.py
> git add servertable.py  # here I probably left that <<<< HEAD line
> git rebase --continue
> vi servertable.py 
> git add servertable.py
> git rebase --continue   # I think this already segfaulted
> git status
> df                      # plenty of free space
> git rebase --abort
> rm .git/MERGE_RR.lock
>
>
> Since the patch is about rerere, I now did:
>
> wrpc:~/tmp/kajongg (master|REBASE-i) git rerere status
> src/servertable.py
> wrpc:~/tmp/kajongg (master|REBASE-i) git rerere diff
> error: Could not stat .git/rr-cache/a8ec6f624ee23ef2e37148a8172ebac3c6639f93/preimage: No such file or directory
> fatal: unable to generate diff for '.git/rr-cache/a8ec6f624ee23ef2e37148a8172ebac3c6639f93'
>
> wrpc:~/tmp/kajongg/.git/rr-cache (GIT_DIR!|REBASE-i) ls -lrt | tail -3
> drwxr-xr-x 2 wr wr 4096 Mar 24 16:19 e6c7ce944f313fa718cad6875d4ee784c098868c
> drwxr-xr-x 2 wr wr 4096 Mar 24 16:19 d0a20608fa0aafd2b234cce432ce7af567c1a94a
> drwxr-xr-x 2 wr wr 4096 Mar 24 16:43 a8ec6f624ee23ef2e37148a8172ebac3c6639f93
> wrpc:~/tmp/kajongg/.git/rr-cache (GIT_DIR!|REBASE-i) ls -l a8ec6f624ee23ef2e37148a8172ebac3c6639f93/
> total 0

Re: segfault with git rebase --abort

[Marcel Röthke]

On 2024-03-25 13:46:47, Junio C Hamano wrote:
> Wolfgang Rohdewald <wolfgang@rohdewald.de> writes:
> I think I forgot to remove one line of "<<<<<<< HEAD" before doing the first git add.

This was the missing piece in my reproduction attempts!
When you leave that line in and have another conflict in the same file
later in the rebase, rerere falls on its nose.

I will do some more poking and update my patch accordingly.