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