From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,
Guillaume Chauvel <guillaume.chauvel@gmail.com>,
Philippe Blain <levraiphilippeblain@gmail.com>,
"Mark C. Chu-Carroll" <markchucarroll@fastmail.com>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 2/2] packfile: fix corruption due to stale delta base cache entries
Date: Tue, 06 Oct 2026 12:57:41 -0700 [thread overview]
Message-ID: <xmqqse2id2kq.fsf@gitster.g> (raw)
In-Reply-To: <20261006-pks-packfile-stale-delta-base-cache-v2-2-69669a2fc6ce@pks.im> (Patrick Steinhardt's message of "Tue, 06 Oct 2026 12:20:15 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> Note that the added test reliably reproduces the above bug on my machine
> that uses NixOS at c59305bab206 (cosmic-applets: add missing runtime
> dependency (#566040), 2026-10-01) with glibc 2.44-25. But as we rely on
> specific allocation behaviour of glibc it is very likely that the test
> will not work on other platforms.
In other words, the test will not detect the bug, when the fix is
reverted, unless the glibc allocator is used?
Adding an unreliable reproducer for a bug that is already fixed may
be of dubious value. However, even if the test is unreliable (since
other allocators might hide the bug when the fix is reverted), it
may be OK as long as it catches the bug on widely used
configurations and does not trigger false positives. On the other
hand, the earlier suggestion to write custom low-level code to
simulate a colliding allocation address somehow smells like a
maintenance burden to me.
Thanks.
next prev parent reply other threads:[~2026-10-06 19:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 7:34 [PATCH 0/2] packfile: fix corruption due to stale delta base cache entries Patrick Steinhardt
2026-10-02 7:34 ` [PATCH 1/2] packfile: move around `close_pack()` Patrick Steinhardt
2026-10-02 19:02 ` Mark C. Chu-Carroll
2026-10-02 19:38 ` Patrick Steinhardt
2026-10-02 7:34 ` [PATCH 2/2] packfile: fix corruption due to stale delta base cache entries Patrick Steinhardt
2026-10-02 13:34 ` Guillaume Chauvel
2026-10-02 19:34 ` Patrick Steinhardt
2026-10-02 17:48 ` Philippe Blain
2026-10-02 19:37 ` Patrick Steinhardt
2026-10-02 22:23 ` Jeff King
2026-10-05 5:32 ` Patrick Steinhardt
2026-10-07 8:18 ` Jeff King
2026-10-07 18:00 ` Junio C Hamano
2026-10-06 10:20 ` [PATCH v2 0/2] " Patrick Steinhardt
2026-10-06 10:20 ` [PATCH v2 1/2] packfile: move around `close_pack()` Patrick Steinhardt
2026-10-06 10:20 ` [PATCH v2 2/2] packfile: fix corruption due to stale delta base cache entries Patrick Steinhardt
2026-10-06 19:57 ` Junio C Hamano [this message]
2026-10-07 5:29 ` Patrick Steinhardt
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=xmqqse2id2kq.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=guillaume.chauvel@gmail.com \
--cc=levraiphilippeblain@gmail.com \
--cc=markchucarroll@fastmail.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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