# Help to understand that call trace

## Logicien

So far, there is only one message who can indicate the source of the call trace before it appear

```
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.

----------

## khayyam

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

----------

## wcg

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.)

----------

## Yamakuzure

Little addition: You might want to take a look at /usr/src/linux/Documentation/kmemleak.txt.

----------

## wcg

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?

----------

## wcg

 *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.

----------

