From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, "Randall S. Becker" <randall.becker@nexbridge.ca>
Subject: Re: [PATCH 0/4] reftable: fix out-of-memory errors on NonStop
Date: Sat, 21 Dec 2024 08:52:17 -0800 [thread overview]
Message-ID: <xmqqv7vdc726.fsf@gitster.g> (raw)
In-Reply-To: <20241221-b4-pks-reftable-oom-fix-without-readers-v1-0-12db83a3267c@pks.im> (Patrick Steinhardt's message of "Sat, 21 Dec 2024 12:50:06 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> this small patch series fixes out-of-memory errors on NonStop with the
> reftable backend. These errors are caused by zero-sized allocations,
> which return `NULL` pointers on NonStop.
Interesting. Git side has long been aware of this issue, but
because being able to get something out of zero-byte allocation was
somehow deemed so useful (and I do not either remember the reasons,
nor if I were asked today, I do not know if I agree), our xmalloc()
and friends ensure that we never return NULL for 0-sized allocation.
I looked at the patches the places they touch and they are sensible
changes to avoid asking 0-sized allocations. Which is the opposite
approach from what Git takes *and* which may be more sensible. The
callers should know better what they want to do when they have zero
sized request. E.g., if they have 0 records to write to in a format
that has num-records followed by an array of entries, they may want
to make it a no-op, or they may want to explicitly write 0 followed
by no entries, to record the fact that such a request was made.
One possible downside of the approach is that all API functions must
be vetted for their response to a request that might end up leading
to a zero-sized allocation and told to special case such a request,
but that is something better donw sooner rather than later.
Will queue. Thanks.
next prev parent reply other threads:[~2024-12-21 16:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-21 11:50 [PATCH 0/4] reftable: fix out-of-memory errors on NonStop Patrick Steinhardt
2024-12-21 11:50 ` [PATCH 1/4] reftable/stack: don't perform auto-compaction with less than two tables Patrick Steinhardt
2024-12-21 17:08 ` Junio C Hamano
2024-12-21 17:51 ` Junio C Hamano
2024-12-22 7:13 ` Patrick Steinhardt
2024-12-21 11:50 ` [PATCH 2/4] reftable/merged: fix zero-sized allocation when there are no readers Patrick Steinhardt
2024-12-21 12:40 ` Kristoffer Haugsbakk
2024-12-21 14:18 ` Patrick Steinhardt
2024-12-21 17:13 ` Junio C Hamano
2024-12-21 11:50 ` [PATCH 3/4] reftable/stack: " Patrick Steinhardt
2024-12-21 17:36 ` Junio C Hamano
2024-12-21 17:57 ` Junio C Hamano
2024-12-21 18:06 ` rsbecker
2024-12-21 18:30 ` Junio C Hamano
2024-12-22 17:48 ` rsbecker
2024-12-22 18:17 ` rsbecker
2024-12-22 18:35 ` Patrick Steinhardt
2024-12-23 4:08 ` Junio C Hamano
2024-12-22 7:13 ` Patrick Steinhardt
2024-12-21 11:50 ` [PATCH 4/4] reftable/basics: return NULL on zero-sized allocations Patrick Steinhardt
2024-12-21 12:53 ` Kristoffer Haugsbakk
2024-12-21 15:05 ` [PATCH 0/4] reftable: fix out-of-memory errors on NonStop Randall Becker
2024-12-21 17:43 ` Junio C Hamano
2024-12-21 16:52 ` Junio C Hamano [this message]
2024-12-22 7:24 ` [PATCH v2 " Patrick Steinhardt
2024-12-22 7:24 ` [PATCH v2 1/4] reftable/stack: don't perform auto-compaction with less than two tables Patrick Steinhardt
2024-12-22 7:24 ` [PATCH v2 2/4] reftable/merged: fix zero-sized allocation when there are no readers Patrick Steinhardt
2024-12-22 7:24 ` [PATCH v2 3/4] reftable/stack: " Patrick Steinhardt
2024-12-22 7:24 ` [PATCH v2 4/4] reftable/basics: return NULL on zero-sized allocations Patrick Steinhardt
2024-12-22 16:31 ` [PATCH v2 0/4] reftable: fix out-of-memory errors on NonStop Junio C Hamano
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=xmqqv7vdc726.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=randall.becker@nexbridge.ca \
/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.