Investigating kext memory leak with lldb and KDK

Is there a way I can use the lldb user defined commands, which I can load from a KDK, to determine how much memory my kext has consumed? Is there a way to figure out what size blocks they are?

Sort of. Keep in mind that your KEXT is simply a loadable library running inside the component, not an independant process/component. Just like in a user space process, there are a variety of mechanisms in place to associate memory allocations to components, but the information you get depends entirely on exactly what you're doing and why.

In terms of commands, the kernel debugging command set has 400+ separate commands, many of which are specific to memory. You can see the full command list and a summary of each with the lldb command "kgmhelp" and each command accepts "-h" for more specific info. Taking zprint (one of the common starting points for looking at memory issues) as an example:

(lldb) kgmhelp
...
zprint               - Routine to print a summary listing of all the kernel zones
...

(lldb)  zprint -h
zprint:
        Routine to print a summary listing of all the kernel zones
        usage: zprint -J
                Output json
    All columns are printed in decimal
    Legend:
        $ - not encrypted during hibernation
        % - zone is a read-only zone
        A - currently trying to allocate more backing memory from kmem_alloc without VM priv
        C - collectable
        D - destructible
        E - Per-cpu caching is enabled for this zone
        G - currently running GC
        H - exhaustible
        I - zone was destroyed and is no longer valid
        L - zone is being logged
        O - does not allow refill callout to fill zone on noblock allocation
        R - will be refilled when below low water mark
        L - zone is LIFO
    

    -h  Show the help string for the command.
    -c [always|auto|never|0|1]
                            Control the colorized output of certain commands
    -o <path/to/filename>   The output of this command execution will be saved to file. Parser information or errors will
                            not be sent to file though. eg /tmp/output.txt
    -s <filter_string>      The "filter_string" param is parsed to python regex expression and each line of output
                            will be printed/saved only if it matches the expression.
    -v [-v...]  Each additional -v will increase the verbosity of the command.
    -p <plugin_name>        Send the output of the command to plugin. Please see README for usage of plugins.

Finally, keep in mind that the kernel's relationship with VM means you can disrupt memory in ways that don't really match the standard definition of a "leak". For example, if you wire another processes memory and fail to unwire it before dropping it that will consume wired memory until the owning process is destroyed, even though you never directly allocated or really "owned" that memory.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware