more debugging enabled in rawhide kernels.
davej at redhat.com
Thu Jun 25 14:58:21 UTC 2009
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.
More information about the devel