From 5800615be7a8388e6f8eef0a64c66a28f12aa2ff Mon Sep 17 00:00:00 2001 From: lawnjelly Date: Tue, 6 Sep 2022 06:51:45 +0100 Subject: [PATCH] Batching - fix uninitialized color read Valgrind was showing a read from uninitialized memory. r_fill_state.curr_batch->color is unset (for performance reasons), so can contain random data. This actually doesn't matter in practice, since logically this uninitialized state can only occur when change_batch is set, and the only side effect is that change_batch is set. Hence why no bugs occur in practice. This PR prevents this read from uninitialized data. It is likely free in terms of performance after optimization, and keeps the Valgrind logs clearer, so why not. (cherry picked from commit 23fedc0d1a5b65592c2381322d7702007a6d849b) --- drivers/gles_common/rasterizer_canvas_batcher.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gles_common/rasterizer_canvas_batcher.h b/drivers/gles_common/rasterizer_canvas_batcher.h index 148056e683c..f42f182e774 100644 --- a/drivers/gles_common/rasterizer_canvas_batcher.h +++ b/drivers/gles_common/rasterizer_canvas_batcher.h @@ -1335,7 +1335,7 @@ PREAMBLE(bool)::_prefill_line(RasterizerCanvas::Item::CommandLine *p_line, FillS // if the color has changed we need a new batch // (only single color line batches supported so far) - if (r_fill_state.curr_batch->color != bcol) { + if (!change_batch && r_fill_state.curr_batch->color != bcol) { change_batch = true; }