GNU bug report logs - #9983
valgrind warning in draw_glyphs

Previous Next

Package: emacs;

Reported by: Dan Nicolaescu <dann <at> gnu.org>

Date: Mon, 7 Nov 2011 04:40:01 UTC

Severity: normal

Done: Dan Nicolaescu <dann <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9983 <at> debbugs.gnu.org
Subject: bug#9983: valgrind warning in draw_glyphs
Date: Mon, 07 Nov 2011 06:52:03 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dan Nicolaescu <dann <at> gnu.org>
>> Date: Sun, 06 Nov 2011 23:36:42 -0500
>> 
>> The warning is for this:
>>         if (check_mouse_face
>>               && mouse_beg_col < start && mouse_end_col > i)
>> 
>> it looks like mouse_beg_col and mouse_end_col could be left uninitialized a few lines above.
>
> I don't see how.  These variables are initialized in this block:
>
> 	  if (row >= mouse_beg_row && row <= mouse_end_row)
> 	    {
> 	      check_mouse_face = 1;
> 	      mouse_beg_col = (row == mouse_beg_row)
> 		? hlinfo->mouse_face_beg_col : 0;
> 	      mouse_end_col = (row == mouse_end_row)
> 		? hlinfo->mouse_face_end_col
> 		: row->used[TEXT_AREA];
> 	    }
>
> check_mouse_face starts as zero, and is only set to 1 in this block.
> So any test that is conditioned on check_mouse_face being non-zero is
> okay with looking at mouse_beg_col and mouse_end_col.
>
> The other variables in the line being flagged, `start' and `i', are
> also okay: `start' is one of the call arguments and `i' is computed
> right before the line being flagged.
>
> Did I miss something?

Hmm, you might be right.  Telling valgrind to attach gdb at that point:

(gdb) info local
overlap_hl = <optimized out>
hlinfo = <optimized out>
mouse_beg_col = 0x0
check_mouse_face = 0x0
dummy_x = 0x0
h = <optimized out>
t = <optimized out>
mouse_end_col = 0x50b3a22
head = 0x7feffe3a0
tail = 0x7feffe3a0
s = <optimized out>
clip_head = 0x0
clip_tail = 0x0
i = <optimized out>
j = <optimized out>
x_reached = 0x184
last_x = 0x2ec
area_left = 0x1c
f = 0x5157bf0

Maybe a compiler problem, evaluating the && in the wrong order?




This bug report was last modified 13 years and 199 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.