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 post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]