On Wed, Nov 10, 2010 at 5:23 PM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > On Wed, 2010-11-10 at 11:41 +0000, Sankar P wrote: >> On Thu, Oct 28, 2010 at 1:54 PM, Catalin Marinas >> <catalin.marinas@xxxxxxx> wrote: >> > On Wed, 2010-10-27 at 20:24 +0100, Sankar P wrote: >> >> Now I removed the "static __init" from the hello_init function and I >> >> got an output of: >> >> >> >> unreferenced object 0xf9042000 (size 512): >> >> Â comm "insmod", pid 12068, jiffies 13995923 (age 51.096s) >> >> Â hex dump (first 32 bytes): >> >> Â Â 6f 64 75 6c 65 00 00 00 00 00 00 2e 73 79 6d 74 Âodule.......symt >> >> Â Â 61 62 00 2e 73 74 72 74 61 62 00 2e 73 68 73 74 Âab..strtab..shst >> >> Â backtrace: >> >> Â Â [<c10b0001>] create_object+0x114/0x1db >> >> Â Â [<c148b4d0>] kmemleak_alloc+0x21/0x3f >> >> Â Â [<c10a43e9>] __vmalloc_node+0x83/0x90 >> >> Â Â [<c10a44b9>] vmalloc+0x1c/0x1e >> >> Â Â [<f9036021>] init_module+0x21/0x2f [hello_kernel] >> >> Â Â [<c1001226>] do_one_initcall+0x71/0x113 >> >> Â Â [<c1056c48>] sys_init_module+0x1241/0x1430 >> >> Â Â [<c100284c>] sysenter_do_call+0x12/0x22 >> >> Â Â [<ffffffff>] 0xffffffff >> > >> > That's because once a module was initialised, the __init functions and >> > ksym entries are removed from the module, to save space. When a memory >> > allocation takes place, kmemleak stores the backtrace as pointers to >> > code. When reporting a leak, it does the ksym look-up to match the >> > address against a function name. >> >> FWIW, I made a blog post explaining my experience, so that if someone >> googles in future for linux kernel memory leak detection, it might >> help them. thank you all. >> >> http://psankar.blogspot.com/2010/11/detecting-memory-leaks-in-kernel.html > > Great, thanks for writing this. > > BTW, the reason kmemleak doesn't immediately show a memory leak even > after forced scanning is because of some heuristics I put in there to > avoid false positives. > > Kmemleak cannot stop the kernel while scanning as this may take a long > time (sometimes minutes). Many objects are kept in lists and, especially > on SMP systems, removing an element from a list may cause kmemleak to > report a lot of false positives temporarily. > > To avoid this, kmemleak builds a checksum (crc32) of each memory block > during scanning. It only reports a leak if the checksum hasn't changed > since the previous scan (otherwise it means that something is still > modifying the object and that's the case with many list_head members, so > not a real leak). > > That proved to be a very good way to reduce the false positives but > kmemleak now needs to scan the memory twice before reporting a real > leak. Not a problem though. > Ah, Okay. Thanks for the explanation and the kind words :-) -- Sankar P http://psankar.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
