Re: [BUG] git diff --no-index segfaults on large files (NULL object database)

From: Tian Yuchen <cat@malon.dev>
Date: Apr 5, 2026, 02:48 UTC
Message-ID: <7841c013-1f6e-49e3-9f47-f25044764a11@malon.dev>
In-Reply-To: <20260404230939.GA1360412@coredump.intra.peff.net>

On 4/5/26 07:09, Jeff King wrote:

Show 18 quoted lines

> Alternatively, should the odb transaction system be more forgiving here,
> and act as a noop when there is no odb?
> 
> Bisecting the segfault yields ce1661f9da (odb: add transaction
> interface, 2025-09-16). Before then, we passed around the
> object_database itself, saw that its transaction field was NULL, and
> returned immediately. After that commit, we pass the object_databse to
> odb_transaction_begin(), which narrows it to odb->sources (which is
> NULL) while passing to object_file_transaction_begin(). And then that
> function looks at source->odb to go back to the object_database! But
> the source being NULL, it segfaults.
> 
> Immediately after that commit, the switch from taking an odb to a source
> is not helpful, though I think eventually it is used to set
> transaction->base.source. But should the whole thing check for a NULL
> source and return early? Or otherwise establish some kind of noop
> transaction?
>

In a nutshell, are you suggesting that odb_transaction_begin() should return silently when source is NULL?

I understand and agree with your intention, but in practical terms, if the odb has not been initialised correctly, data will be lost silently here and the caller will not receive an error message. I’m concerned that doing this might lead to more bugs in certain situations

Would it make more sense to treat this as a bug instead, e.g. by triggering a BUG() when source is NULL?

Show 8 quoted lines

> I haven't thought about the implications (nor even really looked at odb
> transaction code before). But doing it that way would fix not only this
> bug, but also other potential bugs throughout the code base when callers
> start a noop transaction.
> 
> +cc Justin (author of ce1661f9da) for any thoughts.
> 
> -Peff

Thanks! Yuchen