[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2e108260805100622n52e4e555p73ffadc5b882b6df@mail.gmail.com>
Date: Sat, 10 May 2008 15:22:51 +0200
From: "Bart Van Assche" <bart.vanassche@...il.com>
To: "Andi Kleen" <andi@...stfloor.org>
Cc: "Vegard Nossum" <vegard.nossum@...il.com>,
"John Reiser" <jreiser@...wagon.com>,
"Pekka Enberg" <penberg@...helsinki.fi>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Ingo Molnar" <mingo@...e.hu>,
"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"Christoph Lameter" <clameter@....com>,
"Daniel Walker" <dwalker@...sta.com>,
"Randy Dunlap" <randy.dunlap@...cle.com>,
"Josh Aune" <luken@...er.org>, "Pekka Paalanen" <pq@....fi>
Subject: Re: [ANNOUNCE] kmemcheck v7
On Sat, May 10, 2008 at 2:37 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> - kmemcheck can only warn for dynamic memory, whereas kmemcheck I
>> believe will also work for local variables, static variables, etc.
>
> I don't think that's true. valgrind can only detect uninitialized
> local variables in one special case (first use of the stack region).
> But as soon as you reuse stack which is pretty common it won't
> be able to detect the next uninitialized use in a stack frame.
As long as the compiler is not told to optimize the compiled code,
Valgrind's memcheck tool is able to detect uninitialized local
variables. Valgrind a.o. tracks all updates of the stack pointer. If
the stack pointer is increased, the memory range between the old and
the new stack pointer is marked as undefined. This works as long as
gcc doesn't optimize away individual stack pointer updates. (I'm one
of the Valgrind developers.)
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists