From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#9990: valgrind warning in add_row_entry Date: Fri, 11 Nov 2011 17:30:58 +0200 Message-ID: <83zkg2fzgt.fsf@gnu.org> References: <83k47ailf0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1321025641 28748 80.91.229.12 (11 Nov 2011 15:34:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2011 15:34:01 +0000 (UTC) Cc: 9990@debbugs.gnu.org To: Dan Nicolaescu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 11 16:33:54 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 1ROt71-0004Ny-Qh for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 16:33:52 +0100 Original-Received: from localhost ([::1]:58613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROt71-0002gg-EV for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Nov 2011 10:33:51 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:56481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROt6x-0002fD-Us for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 10:33:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROt6v-0003lz-Sl for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 10:33:47 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROt6v-0003lr-RA for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 10:33:45 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ROt7C-0005lh-9D for bug-gnu-emacs@gnu.org; Fri, 11 Nov 2011 10:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Nov 2011 15:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9990 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9990-submit@debbugs.gnu.org id=B9990.132102560222124 (code B ref 9990); Fri, 11 Nov 2011 15:34:02 +0000 Original-Received: (at 9990) by debbugs.gnu.org; 11 Nov 2011 15:33:22 +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 1ROt6X-0005km-JZ for submit@debbugs.gnu.org; Fri, 11 Nov 2011 10:33:21 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ROt6U-0005kZ-96 for 9990@debbugs.gnu.org; Fri, 11 Nov 2011 10:33:19 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUI005005RJSU00@a-mtaout22.012.net.il> for 9990@debbugs.gnu.org; Fri, 11 Nov 2011 17:32:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.231.130]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUI005WI5UUJC60@a-mtaout22.012.net.il>; Fri, 11 Nov 2011 17:32:55 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 11 Nov 2011 10:34: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:53809 Archived-At: > From: Dan Nicolaescu > Cc: 9990@debbugs.gnu.org > Date: Fri, 11 Nov 2011 00:56:18 -0500 > > I got another (maybe) similar one. For this one I had the option that > shows the location of uninitialized variable. This happened after doing C-h H. Is this reproducible? If so, can you tell how to reproduce it? > ==4752== Conditional jump or move depends on uninitialised value(s) > ==4752== at 0x4137ED: update_window (dispnew.c:1276) > ==4752== by 0x414F02: update_window_tree (dispnew.c:3326) > ==4752== by 0x4181CD: update_frame (dispnew.c:3253) > ==4752== by 0x440E7B: redisplay_internal (xdisp.c:13175) > ==4752== by 0x4F0A87: read_char (keyboard.c:2443) > ==4752== by 0x4F2F46: read_key_sequence.constprop.14 (keyboard.c:9290) > ==4752== by 0x4F4C14: command_loop_1 (keyboard.c:1447) > ==4752== by 0x559B55: internal_condition_case (eval.c:1499) > ==4752== by 0x4E7FED: command_loop_2 (keyboard.c:1158) > ==4752== by 0x559A37: internal_catch (eval.c:1256) > ==4752== by 0x4E94EE: recursive_edit_1 (keyboard.c:1123) > ==4752== by 0x515CFB: read_minibuf (minibuf.c:677) > ==4752== Uninitialised value was created by a heap allocation > ==4752== at 0x4A0649D: malloc (vg_replace_malloc.c:236) > ==4752== by 0x5407CF: xrealloc (alloc.c:742) > ==4752== by 0x411001: adjust_glyph_matrix (dispnew.c:580) > ==4752== by 0x41148C: allocate_matrices_for_window_redisplay (dispnew.c:1838) > ==4752== by 0x4119DC: adjust_frame_glyphs (dispnew.c:2167) > ==4752== by 0x416BC9: adjust_glyphs (dispnew.c:1860) > ==4752== by 0x4686A7: Fdelete_other_windows_internal (window.c:2809) > ==4752== by 0x55B9FB: Ffuncall (eval.c:2977) > ==4752== by 0x593BE5: exec_byte_code (bytecode.c:785) > ==4752== by 0x55AE2A: eval_sub (eval.c:2328) > ==4752== by 0x559A37: internal_catch (eval.c:1256) > ==4752== by 0x594567: exec_byte_code (bytecode.c:966) It seems to tell that some glyph row(s) whose glyphs are reallocated here: while (row < end) { row->glyphs[LEFT_MARGIN_AREA] = xnrealloc (row->glyphs[LEFT_MARGIN_AREA], <<<<<<<<<<< dim.width, sizeof (struct glyph)); don't have their hash values initialized, and so this comparison within row_equal_p: if (a == b) return 1; else if (a->hash != b->hash) <<<<<<<<<<<<<<<<<<<<< return 0; else { uses uninitialized value. The strange thing is, the above xnrealloc is not supposed to affect the row's hash value in any way, it just reallocates its glyphs. So I cannot make heads or tails out of this. And the hash value is initialized to zero for additional glyph rows added to a glyph matrix, in this fragment: /* Enlarge MATRIX->rows if necessary. New rows are cleared. */ if (matrix->rows_allocated < dim.height) { int old_alloc = matrix->rows_allocated; new_rows = dim.height - matrix->rows_allocated; matrix->rows = xpalloc (matrix->rows, &matrix->rows_allocated, new_rows, INT_MAX, sizeof *matrix->rows); memset (matrix->rows + old_alloc, 0, (matrix->rows_allocated - old_alloc) * sizeof *matrix->rows); } The call to `memset' should zero out all the fields of each glyph_row that were just added to enlarge the matrix. However, I spotted something strange related to the call to row_equal_p, here: /* Skip over rows equal at the bottom. */ i = last_new; j = last_old; while (i - 1 > first_new && j - 1 > first_old && MATRIX_ROW (current_matrix, i - 1)->enabled_p && (MATRIX_ROW (current_matrix, i - 1)->y == MATRIX_ROW (desired_matrix, j - 1)->y) && !MATRIX_ROW (desired_matrix, j - 1)->redraw_fringe_bitmaps_p && row_equal_p (MATRIX_ROW (desired_matrix, i - 1), MATRIX_ROW (current_matrix, j - 1), 1)) --i, --j; Some of these conditions use incorrect indices to access the glyph matrices: `i' should be used for the current matrix and `j' for the desired matrix. Some of these conditions use `i' and `j' correctly, some don't. So it's possible, for example, that the test of the enabled_p flag produces incorrect results, and we then proceed calling row_equal_p on a row which is not enabled and whose hash was not computed by redisplay.