Re: Major slab mem leak with 2.6.17 / GCC 4.1.1

[Nathan Meyers]

Mike Galbraith wrote:
> On Sun, 2006-10-15 at 10:14 -0400, nmeyers@xxxxxxxxxxxx wrote:
>> On Sun, Oct 15, 2006 at 07:59:14AM +0000, Mike Galbraith wrote:
>>> On Fri, 2006-10-13 at 12:59 +0100, Catalin Marinas wrote:
>>>> On 13/10/06, Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
>>>>> On 10/13/06, nmeyers@xxxxxxxxxxxx <nmeyers@xxxxxxxxxxxx> 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.
>>> 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
>> Thanks for digging that up - I'm building gcc now and will let you
>> know if any useful info emerges.
> 
> Buyer beware of course ;-)
> 
> 	-Mike
> 
> 

So, after all this, what I have to report is: Nothing. Building the same
kernel with which I saw the problem (Gentoo's 2.6.17-r8 ebuild) with the
patched gcc 4.1.1 and the kmemleak patches failed to reproduce the
problem. Either those changes perturbed the kernel enough to "fix" the
problem, or my earlier kernel build was some sort of unrepeatable
miscompile.

I noticed one oddness with the 2.6.17 kmemleak patches when built with
the patched gcc. When I had earlier built with gcc-3.4.6
(CONFIG_DEBUG_MEMLEAK_TRACE_LENGTH=4 and CONFIG_FRAME_POINTER=y),
kmemleak reported good information: every entry included four levels of
stack that clearly mapped to addresses described in System.map. That was
not the case when I built with the patched 4.1.1: every entry included
just one level of stack, with an apparently bogus address that didn't
map into the range of addresses in System.map.

So, in the end, a frustrated experiment. I'll be back if I find anything
interesting. Until then, I'm leaving the list, so please include my
address in any followup conversation. Thanks!

Nathan Meyers
nmeyers@xxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/