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: Tue, 08 Nov 2011 19:17:07 +0200 Message-ID: <83k47ailf0.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1320773138 10423 80.91.229.12 (8 Nov 2011 17:25:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 8 Nov 2011 17:25:38 +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 Tue Nov 08 18:25:32 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 1RNpQN-0004AC-GD for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2011 18:25:27 +0100 Original-Received: from localhost ([::1]:34067 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNpQM-0003iX-OW for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Nov 2011 12:25:26 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:48936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNpQF-0003RD-Li for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2011 12:25:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNpQE-0000Ve-5d for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2011 12:25:19 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNpQD-0000VX-Ow for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2011 12:25:17 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RNpQD-0000RJ-F4 for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2011 12:25:17 -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: Tue, 08 Nov 2011 17:25:16 +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.13207730961610 (code B ref 9990); Tue, 08 Nov 2011 17:25:16 +0000 Original-Received: (at 9990) by debbugs.gnu.org; 8 Nov 2011 17:24:56 +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 1RNpPr-0000Pu-F2 for submit@debbugs.gnu.org; Tue, 08 Nov 2011 12:24:55 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RNpPn-0000PW-GV for 9990@debbugs.gnu.org; Tue, 08 Nov 2011 12:24:53 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LUC00500QIZZM00@a-mtaout22.012.net.il> for 9990@debbugs.gnu.org; Tue, 08 Nov 2011 19:19:09 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.228.42.212]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LUC0039AQRVJST0@a-mtaout22.012.net.il>; Tue, 08 Nov 2011 19:19:09 +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: Tue, 08 Nov 2011 12:25:17 -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:53707 Archived-At: > From: Dan Nicolaescu > Date: Tue, 08 Nov 2011 09:27:06 -0500 > > > valgrind ./temacs -Q gets this warning: > > ==7487== Use of uninitialised value of size 8 > ==7487== at 0x4140F4: update_window (dispnew.c:4212) > ==7487== by 0x414F32: update_window_tree (dispnew.c:3326) > ==7487== by 0x414F0E: update_window_tree (dispnew.c:3324) > ==7487== by 0x4181FD: update_frame (dispnew.c:3253) > ==7487== by 0x443EDB: redisplay_internal (xdisp.c:13175) > ==7487== by 0x4F6F47: read_char (keyboard.c:2443) > ==7487== by 0x4F9406: read_key_sequence.constprop.14 (keyboard.c:9290) > ==7487== by 0x4FB0D4: command_loop_1 (keyboard.c:1447) > ==7487== by 0x560015: internal_condition_case (eval.c:1499) > ==7487== by 0x4EE4AD: command_loop_2 (keyboard.c:1158) > ==7487== by 0x55FEF7: internal_catch (eval.c:1256) > ==7487== by 0x4EFA36: recursive_edit_1 (keyboard.c:1137) > ==7487== > ==7487== > ==7487== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- Y > > The line in question is: > > 4212 entry = row_table[i]; > > > (gdb) p i > $1 = 0x157 > (gdb) p row_table[i] > $2 = (struct row_entry *) 0x0 > (gdb) p row_table_size > $3 = 0x193 > > Is it possible for the contents of row_table to be uninitialized? Is this warning a false positive? row_table and row_table_size are static variables. So at least in temacs they should be initialized to zero, by this code in scrolling_window: n = desired_matrix->nrows; n += current_matrix->nrows; if (row_table_size < 3 * n) { ptrdiff_t size = next_almost_prime (3 * n); row_table = xnrealloc (row_table, size, sizeof *row_table); row_table_size = size; memset (row_table, 0, size * sizeof *row_table); } Because row_table_size is initially zero, the first call to scrolling_window will allocate row_table[] and zero it out. The only call to add_row_entry, the function where line 4212 belongs, is in the same scrolling_window, a few lines _below_ the above fragment that allocates and zeroes out row_table[]. So I don't see how row_table[i] could be uninitialized for any i that is less than row_table_size. Does valgrind know that row_table_size is initially zero because it is static? The other possibility I see is that one or both of w->current_matrix->nrows and w->desired_matrix->nrows are uninitialized. But I think if that were so, Emacs would crash and burn trying to display such a window. Yet another possibility is that the argument ROW passed to add_row_entry is not initialized. Then row->hash is a random value and i inside add_row_entry is also a random value. Can you look at these two loops inside scrolling_window: /* Add rows from the current and desired matrix to the hash table row_hash_table to be able to find equal ones quickly. */ for (i = first_old; i < last_old; ++i) { if (MATRIX_ROW (current_matrix, i)->enabled_p) { entry = add_row_entry (MATRIX_ROW (current_matrix, i)); old_lines[i] = entry; ++entry->old_uses; } else old_lines[i] = NULL; } for (i = first_new; i < last_new; ++i) { xassert (MATRIX_ROW_ENABLED_P (desired_matrix, i)); entry = add_row_entry (MATRIX_ROW (desired_matrix, i)); ++entry->new_uses; entry->new_line_number = i; new_lines[i] = entry; } and see what are the values of first_old, last_old, first_new, and last_new here, and whether the corresponding glyph rows look reasonable, including their hash values? Or maybe just look at the row passed to add_row_entry. You can display a given glyph_row structure with the pgrowx command in GDB (but it won't show the hash value, only how the row will look on the screen). Another command is prowx.