From: "Bart Van Assche" <bart.vanassche@gmail.com>
To: "Andi Kleen" <andi@firstfloor.org>
Cc: "Vegard Nossum" <vegard.nossum@gmail.com>,
"John Reiser" <jreiser@bitwagon.com>,
"Pekka Enberg" <penberg@cs.helsinki.fi>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Ingo Molnar" <mingo@elte.hu>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"Christoph Lameter" <clameter@sgi.com>,
"Daniel Walker" <dwalker@mvista.com>,
"Randy Dunlap" <randy.dunlap@oracle.com>,
"Josh Aune" <luken@omner.org>, "Pekka Paalanen" <pq@iki.fi>
Subject: Re: [ANNOUNCE] kmemcheck v7
Date: Sat, 10 May 2008 15:22:51 +0200 [thread overview]
Message-ID: <e2e108260805100622n52e4e555p73ffadc5b882b6df@mail.gmail.com> (raw)
In-Reply-To: <20080510123744.GB19109@one.firstfloor.org>
On Sat, May 10, 2008 at 2:37 PM, Andi Kleen <andi@firstfloor.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.
next prev parent reply other threads:[~2008-05-10 13:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 13:44 Vegard Nossum
2008-04-04 13:45 ` [PATCH 1/3] kmemcheck: add the kmemcheck core Vegard Nossum
2008-04-04 13:46 ` [PATCH 2/3] x86: add hooks for kmemcheck Vegard Nossum
2008-04-04 13:47 ` [PATCH 3/3] slub: " Vegard Nossum
2008-05-10 9:07 ` [ANNOUNCE] kmemcheck v7 Bart Van Assche
2008-05-10 9:06 ` Pekka Enberg
2008-05-10 11:04 ` Bart Van Assche
2008-05-10 12:02 ` Vegard Nossum
2008-05-10 12:37 ` Andi Kleen
2008-05-10 13:22 ` Bart Van Assche [this message]
2008-05-10 17:17 ` Jeremy Fitzhardinge
2008-05-10 17:48 ` Andi Kleen
2008-05-10 20:45 ` Jeremy Fitzhardinge
2008-05-10 21:29 ` John Reiser
2008-05-10 23:05 ` Jeremy Fitzhardinge
2008-05-10 21:31 ` Andi Kleen
2008-05-10 22:59 ` Jeremy Fitzhardinge
2008-05-10 13:29 ` Bart Van Assche
2008-05-10 17:17 ` Jeremy Fitzhardinge
2008-05-10 20:35 ` Jeff Dike
2008-05-11 11:23 ` John Reiser
2008-05-11 12:08 ` John Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2e108260805100622n52e4e555p73ffadc5b882b6df@mail.gmail.com \
--to=bart.vanassche@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=dwalker@mvista.com \
--cc=jreiser@bitwagon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luken@omner.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=pq@iki.fi \
--cc=randy.dunlap@oracle.com \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®