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

There is a way to do that, write a configuration file and pass it to
valgrind with:  --suppressions=FILENAME

Such a file is attached.

I think it should be checked in src/ so that everyone can make use of it
and improve it.  OK to check in?