[Xymon] Bug in xymon 4.3.4 null template

[Henrik Størner]

Hi Peter,

> 3451 2011-09-01 15:04:31 Sending from devmon to RRD for temp ACpu0Core1:
> 1314853471:45.0
> 3451 2011-09-01 15:04:31 Flushing '/upeterm/temp.ACpu0Core1.rrd' with 2
> updates pending, template *'(null)'*

yes, that would be bad...

> #3 <signal handler called>
> #4 __strncasecmp_l_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:2113
> #5 0x000000000041fd12 in setup_template (params=<value optimised out>)
> at xymonrrd.c:337
> #6 0x00000000004066cf in create_and_update_rrd (hostname=<value
> optimised out>, testname=<value optimised out>, classname=0x7f769a8b226d
> "services",
> pagepaths=0x7f769a8b2276 "0", creparams=0x7fff9d827cc0, template=<value
> optimised out>) at do_rrd.c:501
> #7 0x0000000000412e4b in do_devmon_rrd (hostname=0x7f769a8b221f
> "upeterm", testname=0x7f769a8b2227 "motherboard",
> classname=0x7f769a8b226d "services",
> pagepaths=0x7f769a8b2276 "0", msg=<value optimised out>,
> tstamp=1314851366) at rrd/do_devmon.c:108

Interesting call trace. I cannot map the line numbers to the 4.3.4 
sources; xymond/do_rrd.c line 501 does not contain a call to 
setup_template() - the only call to setup_template() from 
create_and_update_rrd() happens at line 307.

If you compiled this yourself, did you apply any patches ?

> xymon is at 4.3.4
> suggest you add
> if ( cacheitem->tpl->template != NULL) {
> :
> }

No, this isn't the correct fix - it would just try to cover up the 
underlying problem. cacheitem->tpl->template is not supposed to be NULL, 
it can only happen if the code calling into the RRD module provides 
bogus data.

Could you try going back into gdb, then do

    frame 6
    p creparams
    frame 7
    p devmon_params

Another thing you could try for me, please: In xymond/rrd/do_devmon.c, 
could you change the line

    char *devmon_params[MAXCOLS+7];
to
    char *devmon_params[MAXCOLS+7] = { NULL, };

recompile, copy xymond/xymond_rrd into ~xymon/server/bin/, restart Xymon 
and let me know if it makes any difference ?


Thanks,
Henrik