public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Jake Roggenbuck <jakeroggenbuck2@gmail.com>,
	 git@vger.kernel.org, roggenbuckjake@gmail.com
Subject: Re: [PATCH 1/1] Exit on invalid diff status of diff_filepair
Date: Thu, 01 May 2025 06:23:55 -0700	[thread overview]
Message-ID: <xmqq8qngzcpg.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cRehhM-z0md_iV-VYCk_Qwv0A4zS1TfPqPxsrLZ3eYxvA@mail.gmail.com> (Eric Sunshine's message of "Thu, 1 May 2025 02:16:36 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

>>     git (main) $ cd ~/Repos/ECS50-3/hw3-skeleton-broken/
>>     hw3-skeleton-broken (main) $ ~/Build/git/git diff
>>     Segmentation fault (core dumped)
>>     hw3-skeleton-broken (main) $
>>
>> Let me know if you have any feedback or suggestions.
>
> Do you have a reproduction recipe which demonstrates the problem which
> your patch fixes? Including the recipe in the patch's commit message
> would help reviewers better understand the circumstances under which
> the crash occurs since the descriptions provided by both the original
> problem report[1] and the submitted patch[2] seem rather nebulous[3].
>
> More importantly, if you have a reproduction recipe, then it can be
> used as the basis for creating a test which should accompany the patch
> (and which should be added to one of the `t/t40xx-*.sh` files). We can
> help you convert the reproduction recipe into a test if desired.

Nicely put.

It is a bug _elsewhere_ in the code for the .status member to be
unassigned when the control reaches that point, so a patch to exit
after that happens is not all that interesting.  Instead of exiting
there, we would want to see a patch against the place where it
should have set the .status member but fails to do so.

Maybe with a corrupted repository, some of the blob objects we read
for comparison may fail to load and the function may be taking an
early return instead of complaining and dying upon unreadable blob
(I am not saying that is the only or even a likely case; just giving
an example situation for illustrate the point), in which case we
would want to fix _that_ code to complain and die properly.

Thanks.

      reply	other threads:[~2025-05-01 13:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-19  3:02 bug: Segfault with git diff jake roggenbuck
2025-01-08  6:01 ` [PATCH 0/1] Exit on invalid diff status of diff_filepair Jake Roggenbuck
2025-01-08  6:01   ` [PATCH 1/1] " Jake Roggenbuck
2025-04-30 18:50     ` Jake Roggenbuck
2025-04-30 18:50       ` Jake Roggenbuck
2025-05-01  6:16       ` Eric Sunshine
2025-05-01 13:23         ` Junio C Hamano [this message]

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=xmqq8qngzcpg.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jakeroggenbuck2@gmail.com \
    --cc=roggenbuckjake@gmail.com \
    --cc=sunshine@sunshineco.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox