From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 6727D1F4B4 for ; Thu, 1 Apr 2021 19:52:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235271AbhDATwg (ORCPT ); Thu, 1 Apr 2021 15:52:36 -0400 Received: from pb-smtp20.pobox.com ([173.228.157.52]:64331 "EHLO pb-smtp20.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234062AbhDATwf (ORCPT ); Thu, 1 Apr 2021 15:52:35 -0400 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 9EB77127448; Thu, 1 Apr 2021 15:52:35 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=7fE3fQsTYIZS2QVNAzZVoBAPiIY=; b=V0fVPd /msxc8zZxtVREhBLk33jIZtOgSEaVQUt6eZcNMZsuDITDLjXtgboSQ4n0TeaInlW 3a+8ATEWhT/P8SgFNn3bC/onFPlGYAZZcNSvfVUSfu7bklN0TDb9La03Llz/MI2N BH7gXIzg4vqdmMUHG/2jyYlTqcXXUA6CdUhSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=CdEhKfcxHrZy2UCM+hdKvRw63TrrtKzE pdBaQ1WwlUdaulJNNhqbbTn+7iLIjX2kIWE0ZNFnxSVm9OPO2Z2Q43Mwy7clPtD2 q7U0DCv8ZX477LkJWjw45t/jyTjBTZkse8MQLa1myyO+lVbrx2HaG3OYOozxDWom hoyzBB0I3UU= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 97301127447; Thu, 1 Apr 2021 15:52:35 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id D2368127444; Thu, 1 Apr 2021 15:52:32 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Jeff King Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Olga Telezhnaya , git@vger.kernel.org, Taylor Blau , Elijah Newren , Johannes Schindelin Subject: Re: [PATCH] ref-filter: fix NULL check for parse object failure References: <20210308200426.21824-1-avarab@gmail.com> <87k0pnkwej.fsf@evledraar.gmail.com> <87eefvkq5d.fsf@evledraar.gmail.com> Date: Thu, 01 Apr 2021 12:52:31 -0700 In-Reply-To: (Jeff King's message of "Thu, 1 Apr 2021 04:32:24 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: CC7C43D4-9323-11EB-8931-E43E2BB96649-77302942!pb-smtp20.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jeff King writes: > Here's a patch to fix it. This is mostly orthogonal to your patch > series. It happens to use a similar recipe to reproduce, but that is not > the only way to do it, and the fix and the test shouldn't conflict > textually or semantically. > > -- >8 -- > Subject: [PATCH] ref-filter: fix NULL check for parse object failure > > After we run parse_object_buffer() to get an object's contents, we try > to check that the return value wasn't NULL. However, since our "struct > object" is a pointer-to-pointer, and we assign like: > > *obj = parse_object_buffer(...); > > it's not correct to check: > > if (!obj) > > That will always be true, since our double pointer will continue to > point to the single pointer (which is itself NULL). This is a regression > that was introduced by aa46a0da30 (ref-filter: use oid_object_info() to > get object, 2018-07-17); since that commit we'll segfault on a parse > failure, as we try to look at the NULL object pointer. > > There are many ways a parse could fail, but most of them are hard to set > up in the tests (it's easy to make a bogus object, but update-ref will > refuse to point to it). The test here uses a tag which points to a wrong > object type. A parse of just the broken tag object will succeed, but > seeing both tag objects in the same process will lead to a parse error > (since we'll see the pointed-to object as both types). > > Signed-off-by: Jeff King > --- > ref-filter.c | 2 +- > t/t6300-for-each-ref.sh | 10 ++++++++++ > 2 files changed, 11 insertions(+), 1 deletion(-) Makes sense. Will queue. > diff --git a/ref-filter.c b/ref-filter.c > index f0bd32f714..a0adb4551d 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -1608,7 +1608,7 @@ static int get_object(struct ref_array_item *ref, int deref, struct object **obj > > if (oi->info.contentp) { > *obj = parse_object_buffer(the_repository, &oi->oid, oi->type, oi->size, oi->content, &eaten); > - if (!obj) { > + if (!*obj) { > if (!eaten) > free(oi->content); > return strbuf_addf_ret(err, -1, _("parse_object_buffer failed on %s for %s"), > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh > index cac7f443d0..2e7c32d50c 100755 > --- a/t/t6300-for-each-ref.sh > +++ b/t/t6300-for-each-ref.sh > @@ -1134,4 +1134,14 @@ test_expect_success 'for-each-ref --ignore-case works on multiple sort keys' ' > test_cmp expect actual > ' > > +test_expect_success 'for-each-ref reports broken tags' ' > + git tag -m "good tag" broken-tag-good HEAD && > + git cat-file tag broken-tag-good >good && > + sed s/commit/blob/ bad && > + bad=$(git hash-object -w -t tag bad) && > + git update-ref refs/tags/broken-tag-bad $bad && > + test_must_fail git for-each-ref --format="%(*objectname)" \ > + refs/tags/broken-tag-* > +' > + > test_done