Memory leak in Nagios3?

[Ethan Galstad]

Hendrik Bäcker wrote:
> Hi Ethan,
> hi List,
> 
> Ethan Galstad schrieb:
> -----8<-----
>> I think I found it.  There was a mem leak in the date/time macro 
>> generation code.  Patch in CVS now.
>>
> 
> Sorry for answering this kind of late and very thanks for the valgrind
> usage.
> 
> The last cvs code shows even a leak while processing macros for
> performance data files (host and service perfdata).
> 
> As you suggested, the "use_large_installation_tweak" option is disabled,
> ePN is off.
> 
> I think this is the interesting part of the valgrind log.
> 
> ###### Serviceperfdata ########
> ==14288==
> ==14288== 396 bytes in 2 blocks are definitely lost in loss record 25 of 40
> ==14288==    at 0x4022862: realloc (vg_replace_malloc.c:306)
> ==14288==    by 0x807B3B7: process_macros (macros.c:213)
> ==14288==    by 0x80D0508:
> xpddefault_update_service_performance_data_file (xpddefault.c:685)
> ==14288==    by 0x80CFC43: xpddefault_update_service_performance_data
> (xpddefault.c:382)
> ==14288==    by 0x80CEF0C: update_service_performance_data (perfdata.c:91)
> ==14288==    by 0x805D85E: handle_async_service_check_result (checks.c:1567)
> ==14288==    by 0x805A901: reap_check_results (checks.c:173)
> ==14288==    by 0x8077A4D: handle_timed_event (events.c:1238)
> ==14288==    by 0x80770BC: event_execution_loop (events.c:944)
> ==14288==    by 0x80583A9: main (nagios.c:793)
> ==14288==
> ==14288== LEAK SUMMARY:
> ==14288==    definitely lost: 504 bytes in 5 blocks.
> ==14288==    indirectly lost: 336 bytes in 28 blocks.
> ==14288==      possibly lost: 136 bytes in 1 blocks.
> ==14288==    still reachable: 71,936 bytes in 623 blocks.
> ==14288==         suppressed: 0 bytes in 0 blocks.
> ##############
> 
> from a later run:
> 
> ##### Host #########
> ==14511== 1,018 bytes in 4 blocks are definitely lost in loss record 36
> of 46
> ==14511==    at 0x4022862: realloc (vg_replace_malloc.c:306)
> ==14511==    by 0x807B3B7: process_macros (macros.c:213)
> ==14511==    by 0x80D0658: xpddefault_update_host_performance_data_file
> (xpddefault.c:728)
> ==14511==    by 0x80CFC66: xpddefault_update_host_performance_data
> (xpddefault.c:395)
> ==14511==    by 0x80CEF51: update_host_performance_data (perfdata.c:112)
> ==14511==    by 0x8086F32: handle_host_state (sehandlers.c:615)
> ==14511==    by 0x8062951: process_host_check_result_3x (checks.c:3666)
> ==14511==    by 0x8061B76: handle_async_host_check_result_3x (checks.c:3302)
> ==14511==    by 0x805A9A6: reap_check_results (checks.c:194)
> ==14511==    by 0x8077A4D: handle_timed_event (events.c:1238)
> ==14511==    by 0x80770BC: event_execution_loop (events.c:944)
> ==14511==    by 0x80583A9: main (nagios.c:793)
> ==14511==
> ==14511== LEAK SUMMARY:
> ==14511==    definitely lost: 1,126 bytes in 7 blocks.
> ==14511==    indirectly lost: 336 bytes in 28 blocks.
> ==14511==      possibly lost: 0 bytes in 0 blocks.
> ==14511==    still reachable: 72,989 bytes in 726 blocks.
> ==14511==         suppressed: 0 bytes in 0 blocks.
> 
> ##############
> 
> I think, following patch could solve this:
> 
[snip]

Good catch!  Patch will be in CVS shortly.


Ethan Galstad
Nagios Developer
___
Email: nagios at nagios.org
Web:   www.nagios.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/