emacs-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Nicolaescu
Subject: Re: valgrind warnings [Re: Emacs bzr memory footprint]
Date: 2011年11月04日 08:51:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) 
Stefan Monnier <address@hidden> 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?
reply via email to
[Prev in Thread] Current Thread [Next in Thread]

AltStyle によって変換されたページ (->オリジナル) /