threads / discuss / 44339

Fwd: New Defects reported by Coverity Scan for git

Subject: Fwd: New Defects reported by Coverity Scan for git

## tl;dr

9 messages between Oct 20, 2016 and Oct 20, 2016.

replies: 8people: 3as markdown or json

Stefan Beller· Oct 20, 2016, 17:05 UTC · lore

Not sure what triggered the new finding of coverity as seen below as the parse_commit() was not touched. Junios series regarding the merge base optimization touches a bit of code nearby though.

Do we want to replace the unchecked places of parse_commit with parse_commit_or_die ?

Thanks, Stefan _________________________________________________________ *** CID 1374088: Error handling issues (CHECKED_RETURN) /commit.c: 913 in mark_redundant() 907 908 work = xcalloc(cnt, sizeof(*work)); 909 redundant = xcalloc(cnt, 1); 910 ALLOC_ARRAY(filled_index, cnt - 1); 911 912 for (i = 0; i < cnt; i++)

>>>     CID 1374088:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "parse_commit" without checking return value (as is done elsewhere 37 out of 45 times).

913 parse_commit(array[i]); 914 for (i = 0; i < cnt; i++) { 915 struct commit_list *common; 916 917 if (redundant[i]) 918 continue;

Junio C Hamano· Oct 20, 2016, 17:50 UTC · re: Stefan Beller · lore

Re: Fwd: New Defects reported by Coverity Scan for git

Stefan Beller <sbeller@google.com> writes:
Show 6 quoted lines
> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.
>
> Do we want to replace the unchecked places of parse_commit with
> parse_commit_or_die ?

The reason parse_commit() would fail at this point would be because the repository is corrupt, I do not think it would hurt to do such a change.

I agree that it is curious why it shows up as a "new defect", though.

By the way, do you know who is managing the service on our end (e.g. approving new people to be "defect viewer")? The site seems to think I have the power to manage others' subscription, which I do not think I have (I do not go to the site myself). As it spewed quite a many false positives into my mailbox in the past, I do not pay very close attention to these reports these days, but I still read the e-mailed reports every once in a while.

Thanks.
Stefan Beller· Oct 20, 2016, 17:58 UTC · re: Junio C Hamano · lore

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> Not sure what triggered the new finding of coverity as seen below as the
>> parse_commit() was not touched. Junios series regarding the merge base
>> optimization touches a bit of code nearby though.
>>
>> Do we want to replace the unchecked places of parse_commit with
>> parse_commit_or_die ?
>
> The reason parse_commit() would fail at this point would be because
> the repository is corrupt, I do not think it would hurt to do such a
> change.
>
> I agree that it is curious why it shows up as a "new defect",
> though.
>
> By the way, do you know who is managing the service on our end
> (e.g. approving new people to be "defect viewer")?

I do it most of the time, but I did not start managing it. And I have been pretty lax/liberal about handing out rights to do stuff, because I did not want to tip on anyone's toes giving to few rights and thereby annoying them.

I see that some of these emails may be inconvenient to you, I can change your role to defect viewer/contributor if you prefer.

Thanks, Stefan

Junio C Hamano· Oct 20, 2016, 18:05 UTC · re: Stefan Beller · lore

Re: Fwd: New Defects reported by Coverity Scan for git

Stefan Beller <sbeller@google.com> writes:
> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handing out rights to do stuff,
> because I did not want to tip on anyone's toes giving to few rights
> and thereby annoying them.

Good to know that you have been managing it; I was mostly worried about not having anybody managing it (i.e. imagining Coverity nominated/volunteered me as manager with everybody else as viewers) and the new viewer requests get totally ignored by the project as the whole.

> I see that some of these emails may be inconvenient to you, I can
> change your role to defect viewer/contributor if you prefer.

It is not a huge inconvenience to me, because any piece of e-mail that is addressed directly to gitster@ without CC'ing to git@vger and is not a follow-up to any earlier message goes to a separate lowest-priority mailbox that I rarely look at. But if it is easy to recategorize me, please do so.

Thanks.
Stefan Beller· Oct 20, 2016, 18:06 UTC · re: Junio C Hamano · lore

[PATCH] commit parsing: replace unchecked parse_commit by parse_commit_or_die

The reason parse_commit() would fail at these points would be because the repository is corrupt.

This was noticed by coverity.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
 developed on pu as that's where coverity spotted it.
 I have no overview if these areas are being worked on. (It may clash
 with at least jc/merge-base-fp-only)
 
 Thanks,
 Stefan
 builtin/blame.c       | 2 +-
 builtin/describe.c    | 4 ++--
 builtin/name-rev.c    | 2 +-
 builtin/show-branch.c | 4 ++--
 commit.c              | 2 +-
 fetch-pack.c          | 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 992a79c..3b8564c 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1801,7 +1801,7 @@ static void assign_blame(struct scoreboard *sb, int opt)
 		 * so hold onto it in the meantime.
 		 */
 		origin_incref(suspect);
-		parse_commit(commit);
+		parse_commit_or_die(commit);
 		if (reverse ||
 		    (!(commit->object.flags & UNINTERESTING) &&
 		     !(revs->max_age != -1 && commit->date < revs->max_age)))
diff --git a/builtin/describe.c b/builtin/describe.c
index 01490a1..8299b16 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -199,7 +199,7 @@ static unsigned long finish_depth_computation(
 			best->depth++;
 		while (parents) {
 			struct commit *p = parents->item;
-			parse_commit(p);
+			parse_commit_or_die(p);
 			if (!(p->object.flags & SEEN))
 				commit_list_insert_by_date(p, list);
 			p->object.flags |= c->object.flags;
@@ -322,7 +322,7 @@ static void describe(const char *arg, int last_one)
 		}
 		while (parents) {
 			struct commit *p = parents->item;
-			parse_commit(p);
+			parse_commit_or_die(p);
 			if (!(p->object.flags & SEEN))
 				commit_list_insert_by_date(p, &list);
 			p->object.flags |= c->object.flags;
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index cd89d48..92c3316 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -29,7 +29,7 @@ static void name_rev(struct commit *commit,
 	struct commit_list *parents;
 	int parent_number = 1;
 
-	parse_commit(commit);
+	parse_commit_or_die(commit);
 
 	if (commit->date < cutoff)
 		return;
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 974f340..fd911b5 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -218,7 +218,7 @@ static void join_revs(struct commit_list **list_p,
 			parents = parents->next;
 			if ((this_flag & flags) == flags)
 				continue;
-			parse_commit(p);
+			parse_commit_or_die(p);
 			if (mark_seen(p, seen_p) && !still_interesting)
 				extra--;
 			p->object.flags |= flags;
@@ -835,7 +835,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
 		if (!commit)
 			die(_("cannot find commit %s (%s)"),
 			    ref_name[num_rev], oid_to_hex(&revkey));
-		parse_commit(commit);
+		parse_commit_or_die(commit);
 		mark_seen(commit, &seen);
 
 		/* rev#0 uses bit REV_SHIFT, rev#1 uses bit REV_SHIFT+1,
diff --git a/commit.c b/commit.c
index b9c0c81..5b23eaf 100644
--- a/commit.c
+++ b/commit.c
@@ -910,7 +910,7 @@ static void mark_redundant(struct commit **array, int cnt)
 	ALLOC_ARRAY(filled_index, cnt - 1);
 
 	for (i = 0; i < cnt; i++)
-		parse_commit(array[i]);
+		parse_commit_or_die(array[i]);
 	for (i = 0; i < cnt; i++) {
 		struct commit_list *common;
 
diff --git a/fetch-pack.c b/fetch-pack.c
index cb45c34..8b4ab47 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -159,7 +159,7 @@ static const unsigned char *get_rev(void)
 			return NULL;
 
 		commit = prio_queue_get(&rev_list);
-		parse_commit(commit);
+		parse_commit_or_die(commit);
 		parents = commit->parents;
 
 		commit->object.flags |= POPPED;
-- 
2.10.1.448.g862ec83.dirty
Stefan Beller· Oct 20, 2016, 18:13 UTC · re: Junio C Hamano · lore

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 11:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
>
> Good to know that you have been managing it; I was mostly worried
> about not having anybody managing it (i.e. imagining Coverity
> nominated/volunteered me as manager with everybody else as viewers)
> and the new viewer requests get totally ignored by the project as
> the whole.

No, I have been paying attention, but in case I suddenly stop contributing to the git project I thought it's better to have a couple of people there.

Show 9 quoted lines
>
>> I see that some of these emails may be inconvenient to you, I can
>> change your role to defect viewer/contributor if you prefer.
>
> It is not a huge inconvenience to me, because any piece of e-mail
> that is addressed directly to gitster@ without CC'ing to git@vger
> and is not a follow-up to any earlier message goes to a separate
> lowest-priority mailbox that I rarely look at.  But if it is easy
> to recategorize me, please do so.
done.
Jeff King· Oct 20, 2016, 21:42 UTC · re: Stefan Beller · lore

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:
Show 7 quoted lines
> > By the way, do you know who is managing the service on our end
> > (e.g. approving new people to be "defect viewer")?
> 
> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handing out rights to do stuff,
> because I did not want to tip on anyone's toes giving to few rights
> and thereby annoying them.

I also do this, though I admit with more urgency when I recognize the name as somebody who has showed up on the git list.

I wish there was a flag to simply make the results public. There is no point in anybody logging in just to view them, but I don't think Coverity makes that an option.

-Peff
Junio C Hamano· Oct 20, 2016, 22:07 UTC · re: Jeff King · lore

Re: Fwd: New Defects reported by Coverity Scan for git

Jeff King <peff@peff.net> writes:
Show 12 quoted lines
> On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:
>
>> > By the way, do you know who is managing the service on our end
>> > (e.g. approving new people to be "defect viewer")?
>> 
>> I do it most of the time, but I did not start managing it.
>> And I have been pretty lax/liberal about handing out rights to do stuff,
>> because I did not want to tip on anyone's toes giving to few rights
>> and thereby annoying them.
>
> I also do this, though I admit with more urgency when I recognize the
> name as somebody who has showed up on the git list.
Well, then huge thanks to both of you.
Jeff King· Oct 20, 2016, 21:40 UTC · re: Stefan Beller · lore

Re: Fwd: New Defects reported by Coverity Scan for git

On Thu, Oct 20, 2016 at 10:05:38AM -0700, Stefan Beller wrote:
> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.

I have noticed that "old" problems sometimes reappear when nearby code changes. I assume that they have some kind of heuristic to identify the location of a defect, that it probably includes the line number in the file, and that it can be fooled by too much code appearing nearby.

-Peff

← back to recent threads