Running memleak versions

== Memleak Versions ==

Every now and then we suspect memory leaks in OpenZFS, and I might as a user to run the special memleak build.

Usually the process is, if you suspect memleak, you would run

# kstat

and pay attention to the _inuse entries. If one is forever growing, and considerably larger than the soft ceiling we have set, it could be a suspect.

Then a user might be asked to install and run the memleak build of OpenZFS.

It is usually set to record any allocations for a specific bucket, that is a specific size. Typically, KMEM is setup with allocation size bucket, like that of ..., 4096, 8192, 16384, ... (Actually, the buckets are more finally grained than that)

So that an allocation of 4096 will use bucket_4096. But 4097, 4098, ... 8191.. will all have to go into bucket_8192, since they are too big to fit in bucket_4096.

The size is controlled by Registry entries; zfs.memleak_high, and zfs.memleak_low.

While running the memleak version, once the user suspects the leak is happening, we have them dump the cbuf. Ie, write "1" into the Registry.

At the end of cbuf.txt, it might have a section like:

FFFFBE0642F39500: Saving cbuf to \??\C:\Program Files\OpenZFS On Windows\cbuf.txt
FFFFBE0642F39500: SPL: Memory leak report: base=0xfffff804658d0000 size=0xaaf000 (zfswin-2.3.1rc14-5-g03b0eb2c6-dirty)
FFFFBE0642F39500: SPL: kmem_alloc caller zfs_kmem_zalloc_memleak:2852 called 1 times total 4712 bytes
FFFFBE0642F39500: OpenZFS+000000000000FB94 
FFFFBE0642F39500: OpenZFS+000000000000F748 
FFFFBE0642F39500: OpenZFS+00000000002DA3D6 
FFFFBE0642F39500: OpenZFS+00000000002DB9E4 
FFFFBE0642F39500: OpenZFS+0000000000237BE2 

Which you paste into an Issue for the memleak trouble.