From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756838AbYEJNXE (ORCPT ); Sat, 10 May 2008 09:23:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755798AbYEJNWy (ORCPT ); Sat, 10 May 2008 09:22:54 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:64031 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755195AbYEJNWx (ORCPT ); Sat, 10 May 2008 09:22:53 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TZGUPM3EeEwS2FYovYyyqy68RYKZF9wU3jq8TE4Q7KveaAx4ChvxnzCadglY+CJhx21haxULQsU8aUq3S85nxey07g6M9tI4urUErZVvXBMH2UUXlfNvEKi4u5kjgtXGg8rdm8wQNbE6acssS1C89aHUNwb8LfYbXA9iJCVdL5M= Message-ID: Date: Sat, 10 May 2008 15:22:51 +0200 From: "Bart Van Assche" To: "Andi Kleen" Subject: Re: [ANNOUNCE] kmemcheck v7 Cc: "Vegard Nossum" , "John Reiser" , "Pekka Enberg" , "Linux Kernel Mailing List" , "Ingo Molnar" , "Peter Zijlstra" , "Paul E. McKenney" , "Christoph Lameter" , "Daniel Walker" , "Randy Dunlap" , "Josh Aune" , "Pekka Paalanen" In-Reply-To: <20080510123744.GB19109@one.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47F630AE.7050801@gmail.com> <482565A5.8010503@cs.helsinki.fi> <19f34abd0805100502k150e3636x33831230d688dd92@mail.gmail.com> <20080510123744.GB19109@one.firstfloor.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 10, 2008 at 2:37 PM, Andi Kleen 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.