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