unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 9983@debbugs.gnu.org
Subject: bug#9983: valgrind warning in draw_glyphs
Date: Mon, 07 Nov 2011 07:44:49 -0500	[thread overview]
Message-ID: <yxq1utkdrum.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <yxqhb2g40bg.fsf@fencepost.gnu.org> (Dan Nicolaescu's message of "Mon, 07 Nov 2011 06:52:03 -0500")

Dan Nicolaescu <dann@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Dan Nicolaescu <dann@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.





  reply	other threads:[~2011-11-07 12:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07  4:36 bug#9983: valgrind warning in draw_glyphs Dan Nicolaescu
2011-11-07  5:49 ` Eli Zaretskii
2011-11-07 11:52   ` Dan Nicolaescu
2011-11-07 12:44     ` Dan Nicolaescu [this message]
2011-11-07 12:59       ` Andreas Schwab
2011-11-07 15:21         ` Dan Nicolaescu
2011-11-07 15:54         ` Eli Zaretskii
2011-11-07 12:21   ` Andreas Schwab
2011-11-07 15:57     ` Eli Zaretskii
2011-11-08 14:17       ` Dan Nicolaescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yxq1utkdrum.fsf@fencepost.gnu.org \
    --to=dann@gnu.org \
    --cc=9983@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).