nagios config check memory leak

Jim Smythe icatchspam at gmail.com
Mon May 23 17:36:19 CEST 2011


I am currently running 3.2.3 and have found a set of configuration
files that results in a memory leak.

I have quite a few machines running nagios and all but one are running
happily with very similar configs (hosts/services differ from machine
to machine, but all other files are identical).

The short version of the problem (see the long version for Valgrind output):
**********************************************************************************
#### Snipit of hostgroup config file that doesn't work (identical on
all machines)
define hostgroup {
    hostgroup_name Consumer Electronics
    alias Consumer Electronics
}

#### running nagios -v ../nagios.cfg get this (please note, the
corrupt characters change every time I run the verify process)
.... lines ommited ....
        Checked 15 hosts.
Checking host groups...
Error: Host 'èð' specified in host group 'Consumer Electronics' is not
defined anywhere!
        Checked 11 host groups.
.... lines ommited ....
Total Errors:   1

#### changing the "C" in consumer electronics to a "c" fixes it (or,
from a cursory check, any letters except "A", "B", or "C") - see
modified snipit
define hostgroup {
    hostgroup_name consumer Electronics
    alias Consumer Electronics
}

##### config check runs perfectly!!!

The longer version:
******************************************************************************************
After seeing this problem, I recompiled nagios and installed using
"install-untstripped".
After that, I ran Valgrind against it and found some invalid reads.
Please see http://pastebin.com/JQYty7mb for the full output.

Part of the output is here:
Processing object config file '/usr/local/nagios/etc/globals/commands.cfg'...
==3640== Invalid read of size 1
==3640==    at 0x40E3FB7: strtok (in /lib/libc-2.5.so)
==3640==    by 0x809E5C3: xodtemplate_register_objects (xodtemplate.c:9836)
==3640==    by 0x80B3154: xodtemplate_read_config_data (xodtemplate.c:403)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)
==3640==  Address 0x43851d0 is 16 bytes inside a block of size 17 free'd
==3640==    at 0x402251D: free (vg_replace_malloc.c:325)
==3640==    by 0x809FB89: xodtemplate_expand_hosts (xodtemplate.c:14009)
==3640==    by 0x80A2721: xodtemplate_expand_hostgroups_and_hosts
(xodtemplate.c:13734)
==3640==    by 0x80A4686: xodtemplate_duplicate_objects (xodtemplate.c:5563)
==3640==    by 0x80B3326: xodtemplate_read_config_data (xodtemplate.c:359)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)
==3640==
==3640== Invalid read of size 1
==3640==    at 0x40E3FDF: strtok (in /lib/libc-2.5.so)
==3640==    by 0x809E5C3: xodtemplate_register_objects (xodtemplate.c:9836)
==3640==    by 0x80B3154: xodtemplate_read_config_data (xodtemplate.c:403)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)
==3640==  Address 0x43851d0 is 16 bytes inside a block of size 17 free'd
==3640==    at 0x402251D: free (vg_replace_malloc.c:325)
==3640==    by 0x809FB89: xodtemplate_expand_hosts (xodtemplate.c:14009)
==3640==    by 0x80A2721: xodtemplate_expand_hostgroups_and_hosts
(xodtemplate.c:13734)
==3640==    by 0x80A4686: xodtemplate_duplicate_objects (xodtemplate.c:5563)
==3640==    by 0x80B3326: xodtemplate_read_config_data (xodtemplate.c:359)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)

==3640== HEAP SUMMARY:
==3640==     in use at exit: 1,076 bytes in 61 blocks
==3640==   total heap usage: 21,137 allocs, 21,076 frees, 912,117
bytes allocated
==3640==
==3640== 177 bytes in 15 blocks are definitely lost in loss record 1 of 2
==3640==    at 0x4022903: malloc (vg_replace_malloc.c:195)
==3640==    by 0x40E319F: strdup (in /lib/libc-2.5.so)
==3640==    by 0x80AADCE: xodtemplate_add_object_property (xodtemplate.c:3356)
==3640==    by 0x80B2126: xodtemplate_process_config_file (xodtemplate.c:795)
==3640==    by 0x80B1DAC: xodtemplate_process_config_dir (xodtemplate.c:607)
==3640==    by 0x80B2AF6: xodtemplate_read_config_data (xodtemplate.c:298)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)
==3640==
==3640== 899 bytes in 46 blocks are definitely lost in loss record 2 of 2
==3640==    at 0x4022903: malloc (vg_replace_malloc.c:195)
==3640==    by 0x40E319F: strdup (in /lib/libc-2.5.so)
==3640==    by 0x80AE343: xodtemplate_add_object_property (xodtemplate.c:3837)
==3640==    by 0x80B2126: xodtemplate_process_config_file (xodtemplate.c:795)
==3640==    by 0x80B1DAC: xodtemplate_process_config_dir (xodtemplate.c:607)
==3640==    by 0x80B2AF6: xodtemplate_read_config_data (xodtemplate.c:298)
==3640==    by 0x8092F3A: read_object_config_data (objects.c:83)
==3640==    by 0x8062D53: read_all_object_data (config.c:240)
==3640==    by 0x80570DB: main (nagios.c:495)
==3640==
==3640== LEAK SUMMARY:
==3640==    definitely lost: 1,076 bytes in 61 blocks
==3640==    indirectly lost: 0 bytes in 0 blocks
==3640==      possibly lost: 0 bytes in 0 blocks
==3640==    still reachable: 0 bytes in 0 blocks
==3640==         suppressed: 0 bytes in 0 blocks
==3640==
==3640== For counts of detected and suppressed errors, rerun with: -v
==3640== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 21 from 10)

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay




More information about the Developers mailing list