bug#9990: valgrind warning in add_row_entry

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Cc: 9990@debbugs.gnu.org
>> Date: Tue, 15 Nov 2011 11:58:50 -0500
>> 
>> > If the hash values are always correct where they are used, I guess
>> > that excludes the possibility that we use an uninitialized value,
>> > right?
>> 
>> I even added an  xassert (verify_row_hash (row)) in add_row_entry, and
>> it does not trigger.  Strange...
>
> I added such an assert to the trunk.  I also fixed a couple of
> functions that were destroying the validity of hash codes while
> manipulating glyph rows.
>
> Could you please see if valgrind still complains about add_row_entry
> with the current trunk?

Unfortunately it still complains in:

==11270==    at 0x41314F: adjust_glyph_matrix (dispnew.c:612)
==11270==    by 0x4135FC: allocate_matrices_for_window_redisplay 
(dispnew.c:1869)
==11270==    by 0x413B8A: adjust_frame_glyphs (dispnew.c:2199)
==11270==    by 0x417137: adjust_glyphs (dispnew.c:1897)
==11270==    by 0x44243E: redisplay_internal (xdisp.c:12715)
==11270==    by 0x4F6CE2: command_loop_1 (keyboard.c:1589)
==11270==    by 0x55BB45: internal_condition_case (eval.c:1499)
==11270==    by 0x4E9EAD: command_loop_2 (keyboard.c:1158)
==11270==    by 0x55BA27: internal_catch (eval.c:1256)
==11270==    by 0x4EB436: recursive_edit_1 (keyboard.c:1137)
==11270==    by 0x4EB76B: Frecursive_edit (keyboard.c:821)
==11270==    by 0x40E62C: main (emacs.c:1707)

==11270==    by 0x415762: update_window (dispnew.c:4244)
==11270==    by 0x4166C2: update_window_tree (dispnew.c:3360)
==11270==    by 0x418617: update_frame (dispnew.c:3287)
==11270==    by 0x44207B: redisplay_internal (xdisp.c:13175)
==11270==    by 0x4F6CE2: command_loop_1 (keyboard.c:1589)
==11270==    by 0x55BB45: internal_condition_case (eval.c:1499)
==11270==    by 0x4E9EAD: command_loop_2 (keyboard.c:1158)
==11270==    by 0x55BA27: internal_catch (eval.c:1256)
==11270==    by 0x4EB436: recursive_edit_1 (keyboard.c:1137)

[line numbers in dispnew.c might be off by a few lines, I have some
debugging printfs inserted there]