[Top][All Lists]

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

bug#9990: valgrind warning in add_row_entry

From: Eli Zaretskii
Subject: bug#9990: valgrind warning in add_row_entry
Date: Tue, 08 Nov 2011 19:17:07 +0200

> From: Dan Nicolaescu <address@hidden>
> 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

  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

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;
        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_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

reply via email to

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