All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: "Jeff King" <peff@peff.net>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"René Scharfe" <l.s.r@web.de>
Subject: Re: Fwd: New Defects reported by Coverity Scan for git
Date: Tue, 18 Jul 2017 10:23:40 -0700	[thread overview]
Message-ID: <xmqqa841fylf.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kaPFDMn2K0f529-Crzv+vhU3XUMsSM6w3QV4RXKBv5s_g@mail.gmail.com> (Stefan Beller's message of "Tue, 18 Jul 2017 09:59:20 -0700")

Stefan Beller <sbeller@google.com> writes:

> I looked at this report for a while. My current understanding:
> * its detection was triggered by including rs/move-array,
>   f331ab9d4c (use MOVE_ARRAY, 2017-07-15)
> * But it is harmless, because the scan logic does not understand
>   how ALLOC_GROW works. It assumes that
>   done_pbase_paths_alloc can be larger
>   than done_pbase_paths_num + 1, while done_pbase_paths
>   is NULL, such that the memory allocation is not triggered.
>   If that were the case, then we have 2 subsequent dereferences
>   of a NULL pointer right after that. But by inspecting the use
>   of _alloc and _num the initial assumption does not seem possible.

Yes, it does appear that way.  ALLOC_GROW() calls REALLOC_ARRAY()
which safely can realloc NULL to specified size via xrealloc().

I'd be more worried about segfault we seem to be getting only on
Windows from this:

    git -C parent grep -e "(1|2)d(3|4)" --recurse-submodules HEAD^ > actual

in https://travis-ci.org/git/git/jobs/254654195 by the way.



  reply	other threads:[~2017-07-18 17:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <596ddaa620821_77f83e7330107c4@ss1435.mail>
2017-07-18 16:59 ` Fwd: New Defects reported by Coverity Scan for git Stefan Beller
2017-07-18 17:23   ` Junio C Hamano [this message]
2017-07-18 17:41     ` Stefan Beller
2017-07-18 17:55       ` Junio C Hamano
2017-07-18 18:00         ` Brandon Williams
2017-07-18 18:06           ` Stefan Beller
2017-07-20 20:32     ` René Scharfe
2017-07-20 21:52       ` Junio C Hamano
2018-03-26 23:39 Stefan Beller
2018-03-27 10:38 ` Jeff Hostetler
     [not found] <580893d5a4736_4ed37b53181837@ss1435.mail>
2016-10-20 17:05 ` Stefan Beller
2016-10-20 17:50   ` Junio C Hamano
2016-10-20 17:58     ` Stefan Beller
2016-10-20 18:05       ` Junio C Hamano
2016-10-20 18:13         ` Stefan Beller
2016-10-20 21:42       ` Jeff King
2016-10-20 22:07         ` Junio C Hamano
2016-10-20 21:40   ` Jeff King
     [not found] <55bb53d17f78c_2d71521318537c@scan.mail>
2015-07-31 11:24 ` Duy Nguyen
     [not found] <558151df465a5_4fafe3b3182568a@scan.mail>
2015-06-17 13:54 ` Duy Nguyen

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=xmqqa841fylf.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --cc=sbeller@google.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 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.