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

From: Jeff King <peff@peff.net>
Date: May 17, 2016, 21:57 UTC
Message-ID: <20160517215749.GB16905@sigill.intra.peff.net>
In-Reply-To: <573B78CE.1080200@kdbg.org>

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.

Show 11 quoted lines

> 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