[Openipmi-developer] Re: any known leaks (1.4.19 )?

[Corey M. <mi...@ac...>]

Ah, the BMCs on these systems tend to be very slow.  OpenIPMI will
happily queue as much as you give it, so you really need to be careful
to send things and wait for responses before sending anything else.

I've considered adding queue limits, but it's hard to know where to set
them.

-Corey

Noor wrote:

>For this issue, reducing the rate of calls to
>ipmi_sensor_get_reading() and ipmi_sensor_get_states() from applicaion Loop
>helped to reduce *almost* all of the memory loss which was happening.
>
>keeping count of the total outstanding (unexecuted) handlers and  If
>that exceeds a limit
>(say 1000) the appln  refrains from invoking more calls, unless the
>pending calls are completed (reducing the counter).
>
>There is sill a small "leak" though, which iam investigating.
>
>Thanks
>Noor
>
>On 1/23/06, Corey Minyard <mi...@ac...> wrote:
>  
>
>>That particular memory is freed in reading_get_done_handler().  I test
>>with a memory checker in place that detects leaks, but that doesn't mean
>>something hasn't been missed.
>>
>>If you shut everything down, you can see if OpenIPMI has allocated any
>>memory it has not freed.  Look at cmdlang/ipmish.c to see how it does
>>the memory debugging.  Getting everything freed up can be a little
>>challenging, but not impossible.
>>
>>Another option is to run under valgrind, mpatrol, or another memory
>>debugger.  Make sure to *not* run with the OpenIPMI memory debugger then.
>>
>>-Corey
>>
>>Noor wrote:
>>
>>    
>>
>>>Hi ,
>>>
>>>When i use below library call of OpenIPMI (1.4.19 or even 1.4.21) from
>>>an application (linux 2.4.22), i notice a memory leak. The call is
>>>made in an application loop. Mem leak tools
>>>point to  the allocs in stand_ipmi_sensor_get_reading etc and the
>>>absense of corresponding free.
>>>
>>>The library call i make for my callback handler is:
>>>ipmi_sensor_id_get_reading(ipmi_sensor_id_t       sensor_id,
>>>                          ipmi_sensor_reading_cb done,
>>>                          void                   *cb_data)
>>>
>>>In the libray this function, after some levels of nesting, calls:
>>>stand_ipmi_sensor_get_reading() where info ptr is malloc'd.
>>>In error cases ipmi_mem_free(info) is called  immediately in these chain of
>>>function calls.
>>>In success cases it seems to be called when the operation
>>>is done via: reading_get_done_handler.
>>>
>>>Eg:
>>>reading_get
>>>`-sensor_done_check_rsp
>>>   `- reading_get_done_handler <-- ipmi_free_mem() here
>>>
>>>However in cases like below, i dont see the done handler (free).
>>>   reading_get_start
>>>    `-sensor_done_check_rsp
>>>
>>>Could this be a source of leak.
>>>Any pointer on how to debug further, especially to check if the
>>>asynchronous de-queued operations are completed and info ptr is freed?
>>>
>>>do  we need to throttle the rate of above get_reading handler
>>>operation from application?
>>>
>>>Thanks
>>>Noor
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>      
>>>
>>files
>>    
>>
>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>>>_______________________________________________
>>>Openipmi-developer mailing list
>>>Ope...@li...
>>>https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>>>
>>>
>>>      
>>>
>>    
>>