Message - From:
> Sent: Saturday, April 21, 2018 10:53 AM
> Subject: New Defects reported by Coverity Scan for git
>
> > New defect(s) Reported-by: Coverity Scan
> > Showing 1 of 1 defect(s)
> >
On 3/26/2018 7:39 PM, Stefan Beller wrote:
coverity scan failed for the last couple month (since Nov 20th)
without me noticing, I plan on running it again nightly for the
Git project.
Anyway, here are issues that piled up (in origin/pu) since then.
Stefan
-- Forwarded message --
PM
Subject: New Defects reported by Coverity Scan for git
To: sbel...@google.com
Hi,
Please find the latest report on new defect(s) introduced to git found
with Coverity Scan.
44 new defect(s) introduced to git found with Coverity Scan.
32 defect(s), reported by Coverity Scan earlier, were marked
René Scharfe writes:
> We could remove that NULL check -- it's effectively just a shortcut.
> But how would that improve safety? Well, if the array is unallocated
> (NULL) and _num is greater than zero we'd get a segfault without it,
> and thus would notice it. That check currently papers over
Am 18.07.2017 um 19:23 schrieb Junio C Hamano:
> Stefan Beller 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 doe
On Tue, Jul 18, 2017 at 11:00 AM, Brandon Williams wrote:
> On 07/18, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>> >> 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^ >
On 07/18, Junio C Hamano wrote:
> Stefan Beller writes:
>
> >> 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 b
Stefan Beller writes:
>> 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.
>
> Thanks for bringing that to my at
On Tue, Jul 18, 2017 at 10:23 AM, Junio C Hamano wrote:
> Stefan Beller 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 l
Stefan Beller 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 th
does not seem possible.
Stefan
-- Forwarded message --
From:
Date: Tue, Jul 18, 2017 at 2:53 AM
Subject: New Defects reported by Coverity Scan for git
To: sbel...@google.com
Hi,
Please find the latest report on new defect(s) introduced to git found
with Coverity Scan.
2 new
Jeff King writes:
> 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 pre
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 handin
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
On Thu, Oct 20, 2016 at 11:05 AM, Junio C Hamano wrote:
>
> 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 tota
Stefan Beller 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 managin
On Thu, Oct 20, 2016 at 10:50 AM, Junio C Hamano wrote:
> Stefan Beller 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
Stefan Beller 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
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
__
od the modeling
as we intended it. Looking at the first few issues, they seem to be
correctly finding
leaks.
>
>
>>
>> -- Forwarded message --
>> From:
>> Date: Fri, Jul 31, 2015 at 5:54 PM
>> Subject: New Defects reported by Coverity Scan
e);
I'll look into your reference[1] a bit more and try to follow it as a guidance.
>
> ------ Forwarded message ------
> From:
> Date: Fri, Jul 31, 2015 at 5:54 PM
> Subject: New Defects reported by Coverity Scan for git
> To: pclo...@gmail.com
>
>
ed message --
From:
Date: Fri, Jul 31, 2015 at 5:54 PM
Subject: New Defects reported by Coverity Scan for git
To: pclo...@gmail.com
___
*** CID 1313836: Null pointer dereferences (FORWARD_NULL)
On Wed, Jun 17, 2015 at 9:54 PM, Duy Nguyen wrote:
> I think Coverity caught this correctly.
>
> ** CID 1306846: Memory - illegal accesses (USE_AFTER_FREE)
> /builtin/pull.c: 287 in config_get_rebase()
>
>
>
I think Coverity caught this correctly.
** CID 1306846: Memory - illegal accesses (USE_AFTER_FREE)
/builtin/pull.c: 287 in config_get_rebase()
*** CID 1306846: Memory - illegal accesses (
24 matches
Mail list logo
