bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9983: valgrind warning in draw_glyphs


From: Dan Nicolaescu
Subject: bug#9983: valgrind warning in draw_glyphs
Date: Mon, 07 Nov 2011 07:44:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Dan Nicolaescu <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>
>>> From: Dan Nicolaescu <address@hidden>
>>> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]