All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>, git@vger.kernel.org
Subject: Re: [BUG] rebase: can write reflog with uninit. `action` string
Date: Tue, 29 Apr 2025 10:22:14 +0100	[thread overview]
Message-ID: <ce0f41e4-7d90-4398-a0e9-e8ba69791e57@gmail.com> (raw)
In-Reply-To: <20250428194048.149348-1-code@khaugsbakk.name>

Hi Kristoffer

On 28/04/2025 20:40, Kristoffer Haugsbakk wrote:
> From: code@khaugsbakk.name
> 
> We did `git rebase --rebase-merges` on a branch with merge commits.  Including
> back merges.  The reflog after that showed some weird symbols for
> certain merge commits (only merges):
> 
>      e9c962f2ea0 HEAD@{8}: <binary>�: Merged in <branch> (pull request #4441)

Thanks for reporting this. I'm afraid I'm rather confused. In 
run_git_commit() we set GIT_REFLOG_ACTION with

	strvec_pushf(&cmd.env, GIT_REFLOG_ACTION "=%s", ctx->reflog_message);

ctx is allocated with calloc() so ctx->reflog_message is initially NULL. 
At the start of pick_commits() we store the result of 
sequencer_reflog_action() in ctx->reflog_message. That function returns 
a heap allocation that is not freed until we call replay_opts_release() 
at the end of the rebase. If we're doing a normal pick rather than a 
merge we store the result of reflog_message() in ctx->reflog_message. 
That function returns a string stored in a static strbuf. So when we 
call do_merge() from pick_commits() ctx->reflog_message should point to 
a valid string though that string will not hold the correct reflog 
message for the merge because do_merge() does not call reflog_message().

> This is the backtrace when I get the apparently uninit. string:
> 
> ```
> #0  run_git_commit (defmsg=0x555555babe70 "<repo path>/MERGE_MSG", opts=0x7fffffffc070, flags=0) at sequencer.c:1158

Thanks for the backtrace. It would be useful to know what's stored in 
opts->ctx->reflog_message at this point if it's not too much trouble 
please can you run "print *opts" and "print *opts->ctx" here.

Thanks

Phillip

> #1  0x00005555558740d9 in do_merge (r=0x555555a67020 <the_repo>, commit=0x555555b75cb0,
>      arg=0x555555b2164d "<branch stuff> # Merged in <branch> { (pull request #4464)\nlabel branch-point-9\npick 4026b5ced849724bd3857283b6ad50c8609b6d33 only sh"..., arg_len=125, flags=0, check_todo=0x7fffffffb1e0, opts=0x7fffffffc070) at sequencer.c:4380
> #2  0x0000555555876629 in pick_commits (r=0x555555a67020 <the_repo>, todo_list=0x7fffffffbf50, opts=0x7fffffffc070) at sequencer.c:5048
> #3  0x0000555555877eeb in sequencer_continue (r=0x555555a67020 <the_repo>, opts=0x7fffffffc070) at sequencer.c:5480
> #4  0x000055555563a491 in run_sequencer_rebase (opts=0x7fffffffc330) at builtin/rebase.c:369
> #5  0x000055555563bc74 in run_specific_rebase (opts=0x7fffffffc330) at builtin/rebase.c:746
> #6  0x000055555563fe2a in cmd_rebase (argc=0, argv=0x555555a73890, prefix=0x0, repo=0x555555a67020 <the_repo>) at builtin/rebase.c:1878
> #7  0x0000555555574c0d in run_builtin (p=0x555555a34908 <commands+2280>, argc=2, argv=0x555555a73890, repo=0x555555a67020 <the_repo>) at git.c:480
> #8  0x00005555555750ca in handle_builtin (args=0x7fffffffd8a0) at git.c:743
> #9  0x000055555557538c in run_argv (args=0x7fffffffd8a0) at git.c:810
> #10 0x00005555555759e2 in cmd_main (argc=2, argv=0x7fffffffda30) at git.c:950
> #11 0x000055555569b0c3 in main (argc=5, argv=0x7fffffffda18) at common-main.c:9
> ```
> 
> § No reproduction script
> 
> I was unable to reproduce with a simple repo. setup.  I tried:
> 
> 1. Creating a side branch which had a merge
> 2. The side branch conflicted with the other branch
> 3. Rebased with `--rebase-merges`
> 
> -----
> 
> Normal bugreport questionaire follows.
> 
> -----
> 
>      Thank you for filling out a Git bug report!
>      Please answer the following questions to help us understand your issue.
> 
>      What did you do before the bug happened? (Steps to reproduce your issue)
> 
> `git rebase --rebase-merges` on a branch with merge commits.  Including
> back merges.
> 
>      What did you expect to happen? (Expected behavior)
> 
> Normal “action” string for the reflog like for example `continue`:
> 
>      3f90f6ab14d (HEAD -> <branch>) HEAD@{1}: rebase (continue): Merged in <branch> (pull request #4507)
> 
> What happened instead? (Actual behavior)
> 
> The “action” (or whatever it is) string is arbitrary bytes.  Like some
> uninit. memory.
> 
> ```
> e9c962f2ea0 HEAD@{8}: <binary>�: Merged in <branch> (pull request #4441)
> ```
> 
>      What's different between what you expected and what actually happened?
> 
> Apparently uninit. string.
> 
>       Anything else you want to add:
> 
>       Please review the rest of the bug report below.
>       You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.49.0.459.gf65182a99e5
> cpu: x86_64
> built from commit: f65182a99e545d2f2bc22e6c1c2da192133b16a3
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> libcurl: 7.81.0
> OpenSSL: OpenSSL 3.0.2 15 Mar 2022
> zlib: 1.2.11
> SHA-1: SHA1_DC
> SHA-256: SHA256_BLK
> uname: Linux 6.8.0-58-generic #60~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 28 16:09:21 UTC 2 x86_64
> compiler info: gnuc: 11.4
> libc info: glibc: 2.35
> $SHELL (typically, interactive shell): /bin/bash
> 
> 
> [Enabled Hooks]
> 


  reply	other threads:[~2025-04-29  9:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-28 19:40 [BUG] rebase: can write reflog with uninit. `action` string Kristoffer Haugsbakk
2025-04-29  9:22 ` Phillip Wood [this message]
2025-04-29 19:40   ` Kristoffer Haugsbakk
2025-04-29 21:51     ` Jeff King
2025-04-30 15:17       ` Kristoffer Haugsbakk
2025-05-01 13:17         ` Jeff King
2025-05-01 14:36           ` phillip.wood123
2025-05-01 15:36             ` Jeff King
2025-05-01 16:07           ` Junio C Hamano
2025-05-01 16:38             ` Jeff King
2025-05-01 17:53               ` Junio C Hamano
2025-05-01 14:10       ` phillip.wood123

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce0f41e4-7d90-4398-a0e9-e8ba69791e57@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.