View previous topic :: View next topic |
Author |
Message |
Logicien Veteran
Joined: 16 Sep 2005 Posts: 1555 Location: Montréal
|
Posted: Fri Nov 09, 2012 1:43 am Post subject: Help to understand that call trace |
|
|
So far, there is only one message who can indicate the source of the call trace before it appear Code: | kmemleak: Trying to color unknown object at 0xffff88012a80aa80 as Grey
Pid: 0, comm: swapper/0 Not tainted 3.6.5-gentoo #1
Call Trace:
[<ffffffff810cc87f>] ? paint_ptr+0x50/0x8f
[<ffffffff816908e9>] ? sysctl_init+0x16/0x1b
[<ffffffff8167da99>] ? start_kernel+0x38c/0x3cd
[<ffffffff8167d5b0>] ? do_early_param+0x7d/0x7d
[<ffffffff8167d120>] ? early_idt_handlers+0x120/0x120
[<ffffffff8167d331>] ? x86_64_start_kernel+0xd3/0xe2
|
So, this call trace look to come from kmemleak. I do not know what is kmemleak. This kernel have been configure and compile by my self from the Gentoo sources. This is 3.6.5 version, but the call trace is displayed since long before. The kernel work normally. _________________ Paul |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Fri Nov 09, 2012 3:25 pm Post subject: |
|
|
Logicien ...
when colouring "grey" kmemleak is trying to mark it as a false positive. The line above whats quoted should give some idea of what specificaly triggers it.
best ... khay |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Mon Nov 12, 2012 11:40 pm Post subject: |
|
|
What is the function of kmemleak? To notice when the kernel
has allocated memory to which there are no longer any
references, meaning that the address of that memory block
is no longer assigned to any variable, yet the memory block
is still marked as allocated by the kernel.
"Coloring" in this case is kernel shorthand for "allocated but
not referenced", "allocated and referenced", "not allocated,"
etc. False positives can turn up when the address of a block
of memory is on a queue to be freed when the kernel gets
around to it. Until the kernel actually marks it free, it seems
to still be allocated to the kmemleak detector, yet some
structure that once contained a variable that held the address
of that memory block no longer exists (kernel thread exited,
stack was freed, etc). So it is not really a "memory leak",
because the kernel will get around to freeing it eventually,
yet it still looks like a memory leak when kmemleak gets
scheduled.
That is what kmemleak does. Why there is a bug report
would have a more subtle explanation. (I do not know
enough about its internal structure to say.) _________________ TIA |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2285 Location: Adendorf, Germany
|
Posted: Tue Nov 13, 2012 8:10 am Post subject: |
|
|
Little addition: You might want to take a look at /usr/src/linux/Documentation/kmemleak.txt. _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Wed Nov 14, 2012 2:40 pm Post subject: |
|
|
Another added detail: kmemleak should not report a leak when
memory is on a queue to be freed, because the queue itself
contains a reference to that block of memory. That would be a
bug.
There might be race conditions, though, where removing that
variable from the queue and marking that block of memory
as free, unallocated memory is not an atomic operation.
*Something* should always have a reference to that memory
until it is actually marked free, but perhaps there are situations
where kmemleak can not see local stack variables of some
function currently executing in another thread on another
cpu core, for example, and that is the only existing reference
to that memory block.
edit:
Theoretic, functional programming kind of question:
do kmemleak's own function arguments count as
references? _________________ TIA |
|
Back to top |
|
|
wcg Guru
Joined: 06 Jan 2009 Posts: 588
|
Posted: Thu Nov 15, 2012 12:20 am Post subject: |
|
|
Quote: | /usr/src/linux/Documentation/kmemleak.txt |
A good document. When you consider how many kinds of
cases there are where coverage of allocations and references
to them from kernel objects would not be complete, races
between kmemleak and non-atomic deallocation functions
are probably in the noise (not a source of errors common
enough to matter to anyone examining kernel memory leaks).
Here is a good explanation (last time I read it, anyway) of
what "race conditons" are:
http://en.wikipedia.org/wiki/Race_condition
This sentence from kmemleak.txt is pertinent:
Quote: |
Anyway, this tool is intended for debugging purposes where
the performance might not be the most important requirement. |
Most users are not debugging kernel memory leaks, so
they do not need to pay the performance costs of enabling
kmemleak. _________________ TIA |
|
Back to top |
|
|
|