From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.bugs Subject: bug#9983: valgrind warning in draw_glyphs Date: Mon, 07 Nov 2011 07:44:49 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1320669929 13058 80.91.229.12 (7 Nov 2011 12:45:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Nov 2011 12:45:29 +0000 (UTC) Cc: 9983@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 07 13:45:25 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RNOZp-0001ck-Al for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Nov 2011 13:45:25 +0100 Original-Received: from localhost ([::1]:43089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOZo-0001mH-Rd for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 Nov 2011 07:45:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOZl-0001ca-Es for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2011 07:45:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNOZb-0004uy-Nl for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2011 07:45:21 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNOZb-0004ur-Kq for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2011 07:45:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RNOcM-0004vF-FD for bug-gnu-emacs@gnu.org; Mon, 07 Nov 2011 07:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dan Nicolaescu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2011 12:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9983 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9983-submit@debbugs.gnu.org id=B9983.132067006518897 (code B ref 9983); Mon, 07 Nov 2011 12:48:02 +0000 Original-Received: (at 9983) by debbugs.gnu.org; 7 Nov 2011 12:47:45 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNOc5-0004uj-DW for submit@debbugs.gnu.org; Mon, 07 Nov 2011 07:47:45 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNOc2-0004ua-Om for 9983@debbugs.gnu.org; Mon, 07 Nov 2011 07:47:43 -0500 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RNOZF-0006pn-Pk; Mon, 07 Nov 2011 07:44:49 -0500 In-Reply-To: (Dan Nicolaescu's message of "Mon, 07 Nov 2011 06:52:03 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 07 Nov 2011 07:48:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53657 Archived-At: Dan Nicolaescu writes: > Eli Zaretskii writes: > >>> From: Dan Nicolaescu >>> 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 = > hlinfo = > mouse_beg_col = 0x0 > check_mouse_face = 0x0 > dummy_x = 0x0 > h = > t = > mouse_end_col = 0x50b3a22 > head = 0x7feffe3a0 > tail = 0x7feffe3a0 > s = > clip_head = 0x0 > clip_tail = 0x0 > i = > j = > 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.