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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
