Memory leak in Nagios3?

Hendrik Bäcker andurin at process-zero.de
Thu Nov 8 19:31:37 CET 2007


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:

Index: xdata/xpddefault.c
===================================================================
RCS file: /cvsroot/nagios/nagios/xdata/xpddefault.c,v
retrieving revision 1.40
diff -u -r1.40 xpddefault.c
--- xdata/xpddefault.c	24 Oct 2007 18:33:26 -0000	1.40
+++ xdata/xpddefault.c	8 Nov 2007 18:30:13 -0000
@@ -695,6 +695,7 @@

 	/* free memory */
 	my_free(raw_output);
+	my_free(processed_output);

 	return result;
         }
@@ -738,6 +739,7 @@

 	/* free memory */
 	my_free(raw_output);
+	my_free(processed_output);

 	return result;
         }



-------------------------------------------------------------------------
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/




More information about the Developers mailing list