> Hi Dave,
> It seems that function do_radix_tree doesn't free dynamic
> allocated memory and in turn cause memory leak.
> Hope that the attached patch would help.
> Wang Chao
The do_radix_tree() function is not used by any other entity
in the crash utility, but could be used by an extension module.
It was added back in 2004 in crash version 3.8-1 -- before I kept the
changelog file -- and I'm afraid I don't even have a record of who
wrote the original version to give them credit. It was updated slightly
by firstname.lastname@example.org in 2008 (version 4.0-5.1), but as I recently discovered,
it doesn't work for any kernel after linux-2.6.19, because it was written
with a hardwired dependency on the radix_tree_node structure never changing,
and it had hardwired copies of the kernel's RADIX_TREE_MAP_SHIFT,
RADIX_TREE_MAP_SIZE and RADIX_TREE_MAP_MASK #define's.
In any case, for the next crash release, I have resurrected its functionality
by re-writing it to not depend upon the radix_tree_node structure remaining
unchanged, and made the 3 #define's dynamically calculated values. I did so
in order to use do_radix_tree() with an update the "irq" command, so that it
will work with 2.6.34 and later kernels that have replace the irq_desc array
with the irq_desc_tree radix tree.
Anyway, getting back to your patch, while it's certainly good practice to
call FREEBUF() for any prior GETBUF() call, in reality it's not a memory leak.
All buffers allocated with GETBUF() are *only* in effect for the lifetime of a
particular crash command. If any buffers allocated by GETBUF() are not explicitly
freed by FREEBUF(), they will be freed automatically by the free_all_bufs() function
before the next "crash> " prompt. So it's impossible for them to cause a memory
But I'll certainly add the FREEBUF() call in your patch.
Crash-utility mailing list