Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

[Jeff King <peff@peff.net>]

On Tue, May 17, 2016 at 10:02:22PM +0200, Johannes Sixt wrote:

> > Interesting. It replicates out of the box for me.
> 
> "Out of the box" are the magic words. I usually compile with -O0, which
> doesn't trigger the valgrind report.

Heh, I meant that Noam's test worked out of the box. I also build with
-O0. I was able to replicate with different optimization levels.

I think the interesting thing here is actually the libc (and therefore
possibly your valgrind version). I tried compiling with ASAN and get a
color value of "48830". But no ASAN warning!

I think what is happening is that we over-allocate the new_columns array
based on a power of 2, but only initialize up to num_new_columns. So the
off-by-one accesses heap memory that is allocated but which we have
never written to.

> When I compile with a 3.x based gcc on Windows, I see these warnings:
> 
>     CC color.o
> color.c: In function 'color_parse_mem':
> color.c:203: warning: 'c.value' may be used uninitialized in this function
> color.c:203: warning: 'c.blue' may be used uninitialized in this function
> color.c:203: warning: 'c.green' may be used uninitialized in this function
> color.c:203: warning: 'c.red' may be used uninitialized in this function
> 
> (which triggered my curiosity in this bug report). But they seem to be
> unrelated and are most likely false positives.

Yeah, I think that's unrelated. I'd be highly distrustful of
-Wuninitialized in gcc 3.x. We had to mark quite a few false positives
back then, that were later corrected in the 4.x series.

-Peff