[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1160899154.5935.19.camel@Homer.simpson.net>
Date: Sun, 15 Oct 2006 07:59:14 +0000
From: Mike Galbraith <efault@....de>
To: Catalin Marinas <catalin.marinas@...il.com>
Cc: Pekka Enberg <penberg@...helsinki.fi>,
"nmeyers@...tmark.com" <nmeyers@...tmark.com>,
linux-kernel@...r.kernel.org
Subject: Re: Major slab mem leak with 2.6.17 / GCC 4.1.1
On Fri, 2006-10-13 at 12:59 +0100, Catalin Marinas wrote:
> On 13/10/06, Pekka Enberg <penberg@...helsinki.fi> wrote:
> > On 10/13/06, nmeyers@...tmark.com <nmeyers@...tmark.com> wrote:
> > > If anyone has a version of kmemleak that I can build with 4.1.1, or
> > > any other suggestions for instrumentation, I'd be happy to gather more
> > > data - the problem is very easy for me to reproduce.
> >
> > You should cc Catalin for that. Alternatively, you could try
> > CONFIG_DEBUG_SLAB_LEAK.
>
> Thanks for cc'ing me (I'm still on holiday and not following the
> mailing list). The problem is the __builtin_constant_p gcc function
> which doesn't work properly with 4.x versions. It was fixed in latest
> gcc versions though. Kmemleak relies on __builtin_constant_p to
> determine the pointer aliases and without it you would get plenty of
> false positives.
SuSE (for one?) doesn't appear to know about it. gcc version 4.1.2
20060920 (month old prerelease) still has the problem. After some
rummaging around, I found the fix (attached in case someone else wants
to try it).
2.6.19-rc1 + patch-2.6.19-rc1-kmemleak-0.11 compiles fine now (unless
CONFIG_DEBUG_KEEP_INIT is set), boots and runs too.. but axle grease
runs a lot faster ;-) I'll try a stripped down config sometime.
-Mike
View attachment "gcc41-rh198849.patch" of type "text/x-patch" (2797 bytes)
Powered by blists - more mailing lists