Thanks for tracking this down, but the proposed fix doesn't completely solve all out-of-bounds accesses.

The problem here is that BlankSquare is also called with square_color = 2, for blacking out a square. And in that case it should never involve any texture bitmap. So the fundamentally correct solution is to include the condition color < 2 when setting 'texture' in BlankSquare(). I will push a patch for that
to the v4.9 banch of the repo.

Op 2/4/2018 om 9:24 PM schreef Justin Vreeland:
There's an off-by-one error caused when selecting square colors for held pieces
that frequently causes pngBoardBitmap to access a value past it's bounds, which
also is likely to include an invalid status field.

The code in cairo and xboard seem to handle nulls well, this patch
simply expands that array without initializing the final instance.
  draw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draw.c b/draw.c
index 8b788925..f4aa94d2 100644
--- a/draw.c
+++ b/draw.c
@@ -110,7 +110,7 @@ static cairo_surface_t *pngPieceImages[2][(int)BlackPawn];  
 // png 256 x 256 im
  static cairo_surface_t *pngPieceBitmaps[2][(int)BlackPawn];  // scaled pieces 
as used
  static cairo_surface_t *pngPieceBitmaps2[2][(int)BlackPawn]; // scaled pieces 
in store
  static RsvgHandle *svgPieces[2][(int)BlackPawn]; // vector pieces in store
-static cairo_surface_t *pngBoardBitmap[2], *pngOriginalBoardBitmap[2];
+static cairo_surface_t *pngBoardBitmap[3], *pngOriginalBoardBitmap[2];
  int useTexture, textureW[2], textureH[2];
#define pieceToSolid(piece) &pieceBitmap[SOLID][(piece) % (int)BlackPawn]

Reply via email to