On Tue, Jul 18, 2017 at 10:23 AM, Junio C Hamano <[email protected]> wrote: > Stefan Beller <[email protected]> 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.
Thanks for bringing that to my attention, (I do not follow the travis builds as closely, as there is no yelling email in my inbox). Windows builds on travis seem to be flaky. (sometimes they do not start), but there are also successful builds, including the -rc0, which may indicate bw/grep-recurse-submodules may be faulty on Windows.
