GNU bug report logs - #9983
valgrind warning in draw_glyphs

Previous Next

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 07:44:49 -0500

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

> 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?

The assembly in question looks like this:

.LBB3664:
        .loc 1 22981 0
        movl -152(%rbp), %ebx
        cmpl %ebx, -260(%rbp)
        jge  .L7265
        movl -192(%rbp), %eax
        testl            %eax, %eax
        je               .L7265
        .loc 1 22982 0
        movslq -232(%rbp), %rax
        .loc 1 22985 0
        xorl %r14d, %r14d
        cmpq %rax, -120(%rbp)
        setl %r14b
        leal (%r14,%r14,2), %ebx
        movl %ebx, -144(%rbp)

the debugger is stopped on the "jge" line, that means that the "cmpl"
lined did the access.

(gdb) p/d (long long)&mouse_beg_col - (long long)$rbp
$18 = -260
(gdb) p/d (long long)&check_mouse_face - (long long)$rbp
$19 = -192

so it looks like check_mouse_face is tested after mouse_beg_col.
(unless I'm missing something...)

The compiler here is the system compiler on an up to date Fedora15 system.
 gcc --version
gcc (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Previous Next

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