[Lcdproc] Memory leak

[Andre Guibert de Bruet]

On Dec 9, 2008, at 2:00 PM, Andre Guibert de Bruet wrote:

> On Dec 9, 2008, at 1:41 PM, Vallevand, Mark K wrote:
>
>> In server/commands/menu_commands.c there is a malloc without a  
>> corresponding free.  See function argv2string().
>
> Look carefully at what the function is intended to do. The returning  
> of a malloc()'ed buffer is by design. It is up to the caller to call  
> free() against the returned buffer (If it doesn't, you end up with  
> leaking memory).

And it turns out the caller wasn't. Good catch! :)

>> We are seeing a memory leak in LCDd in our embedded product.  This  
>> is the first leak found in the LCDd code, but there may be others.   
>> I’m looking hard because LCDd will grow to fill memory in only 8  
>> days on our product.
>
> If you are using Linux, run LCDd under valgrind on your development/ 
> reference system. It will help point out any memory allocation issues.
>
> As with all software projects there's always room for improvement.  
> Do submit patches!


I cooked up a patch which addresses the issue you have brought up as  
well as a possible NULL-pointer dereference in the malloc() failure  
case.

It turns out that LCDd is leaking memory in the call to debug()  
whether or not debugging is turned on, every time menu_set_item_func()  
gets called! Please give the attached patch a spin and let the list  
know if this helps alleviate the memory issues you are running into on  
your test system.

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */


-------------- next part --------------
A non-text attachment was scrubbed...
Name: argv2string.diff
Type: application/octet-stream
Size: 1245 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081209/2ac806e3/attachment.obj>
-------------- next part --------------