Re: valgrind warnings [Re: Emacs bzr memory footprint]

[Dan Nicolaescu <dann@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> This is while scanning the stack, where it is apparently possible that
>> this happens to look like a Lisp_Object, but isn't.
>
> That doesn't explain it, tho: the conservative stack scanning does check
> to make sure the suspected pointer really does point to a real (tho
> possibly dead) object, and we always know its type.

It turns out there's a --track-origins=yes valgrind flag.  With that
turned on we get this warning:

==9622== Conditional jump or move depends on uninitialised value(s)
==9622==    at 0x5B3D89: mem_find (alloc.c:3521)
==9622==    by 0x5B4AEB: mark_maybe_object (alloc.c:4103)
==9622==    by 0x5B50E6: mark_memory (alloc.c:4275)
==9622==    by 0x5B517E: mark_stack (alloc.c:4533)
==9622==    by 0x5B6048: Fgarbage_collect (alloc.c:5120)
==9622==    by 0x5D542C: eval_sub (eval.c:2217)
==9622==    by 0x602A0B: readevalloop (lread.c:1838)
==9622==    by 0x6015B6: Fload (lread.c:1316)
==9622==    by 0x5D59FF: eval_sub (eval.c:2336)
==9622==    by 0x602A0B: readevalloop (lread.c:1838)
==9622==    by 0x6015B6: Fload (lread.c:1316)
==9622==    by 0x5D59FF: eval_sub (eval.c:2336)
==9622==  Uninitialised value was created by a stack allocation
==9622==    at 0x5B5D00: Fgarbage_collect (alloc.c:4993)
==9622== 

And indeed, there's:
  Lisp_Object total[8];
in Fgarbage_collect.
What should we do about this?