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

[Stefan Monnier]

>>> 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.

Ah, right, so the problem is not that the stack "points" to some
uninitialized value, but that the stack itself contains uninitialized
values.  Yes, that's perfectly harmless (at least no worse than the
arbitrary initialized values we can find).

> What should we do about this?

Tell valgrind that it's a non-issue.


        Stefan