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

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

Fwd: New Defects reported by Coverity Scan for git

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:

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

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

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

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,

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

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

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

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

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

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

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

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) >>

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

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

Fwd: New Defects reported by Coverity Scan for git

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

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

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

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

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

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"

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

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

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

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

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

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

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

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

Fwd: New Defects reported by Coverity Scan for git

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

Fwd: New Defects reported by Coverity Scan for git

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