more debugging enabled in rawhide kernels.

[Dave Jones]

On Thu, Jun 25, 2009 at 01:31:59AM -0400, Warren Togami wrote:
 > On 06/24/2009 08:08 PM, Dave Jones wrote:
 > > In tomorrows rawhide kernel, I've enabled a debugging option
 > > called kmemleak. As the name suggests, this tracks memory allocations,
 > > and prints backtraces in cases where the memory is believed to be lost.
 > >
 > > Things of note:
 > >
 > > - This tracking doesn't come for free, so things may slow down.
 > >    In some cases, perhaps considerably.
 > > - You may see backtraces in dmesg like ..
 > >
 > > kmemleak: unreferenced object 0xdb804c40 (size 20):
 > > kmemleak:   comm "swapper", pid 0, jiffies 4294667296
 > > kmemleak:   backtrace:
 > > kmemleak:     [<c04fd8b3>] kmemleak_alloc+0x193/0x2b8
 > > kmemleak:     [<c04f5e73>] kmem_cache_alloc+0x11e/0x174
 > > kmemleak:     [<c0aae5a7>] debug_objects_mem_init+0x63/0x1d9
 > > kmemleak:     [<c0a86a62>] start_kernel+0x2da/0x38d
 > > kmemleak:     [<c0a86090>] i386_start_kernel+0x7f/0x98
 > > kmemleak:     [<ffffffff>] 0xffffffff
 > >
 > >    Hold off on reporting them just yet. There are some known traces
 > >    (like that one for eg) which we are aware of already, without needing
 > >    tracking bugs for them.  Hopefully we can nail the obvious bugs&
 > >    false positives quickly.
 > >
 > > 	Dave
 > >
 > 
 > Does kerneloops know how to report these?

It should. It's just another backtrace.

Though this is turning up so many false positives I think I'm going to
just disable it again for tomorrows build unless the upstream developer
can make it a lot less noisy quickly.

	Dave