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 --
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 --
From:
Date: Mon, Mar 26, 2018 at 4:24 PM
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
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
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
__
Jeff, I suppose you are the admin of git on scan.coverity, or knows
him/her, perhaps we can add a model for xmalloc to suppress these
"null pointer deferences" reports? We are sure xmalloc() never returns
NULL. Qemu did it [1] and it looks simple.. I think something like
this would do
void *xmallo
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 (
20 matches
Mail list logo