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