[Xymon] logfetch bug or trigger syntax in client-local.cfg?

[Gore, David W (David)]

Henrik,

Could we get some feedback on this since both Jeremy and I are experiencing the problem with different OS clients?  Is it us with our regex, the syntax seems rather straight forward?  

We are receiving core dumps of logfetch at irregular times but it is quite persistent.  This is mostly on SunOS 10 SPARC clients with a 4.3.6 Xymon client build.  Any ideas appreciated. Here is the back trace.  

[nmsbb at ipgomzspa03 client]$ ./gdb bin/logfetch core
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
Core was generated by `/export/home/nmsbb/client/bin/logfetch /export/home/nmsbb/client/tmp/logfetch.i'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.1...done.
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/libaio.so.1...done.
Loaded symbols for /lib/libaio.so.1
Reading symbols from /lib/libmd.so.1...done.
Loaded symbols for /lib/libmd.so.1
Reading symbols from /platform/sun4v/lib/libc_psr.so.1...done.
Loaded symbols for /platform/SUNW,T5240/lib/libc_psr.so.1
#0  0xff282810 in __regexec_C () from /lib/libc.so.1
(gdb) bt
#0  0xff282810 in __regexec_C () from /lib/libc.so.1
#1  0x00012f5c in logdata (filename=0x3b180 "/var/adm/messages", logdef=0x3b13c)
    at logfetch.c:252
#2  0x00014730 in main (argc=1, argv=0x36000) at logfetch.c:963

Relevant portions of code:

Around line 252:

    /* See if this is a trigger line */
    if (logdef->triggercount) {
      int i, match = 0;

      for (i=0; ((i < logdef->ignorecount) && !match); i++) {
        match = (regexec(&trigexpr[i], fillpos, 0, NULL, 0) == 0); ← line 252
      }

      if (match) {
        int sidx;

        sidx = lpidx - LINES_AROUND_TRIGGER;
        if (sidx < 0) sidx += (2*LINES_AROUND_TRIGGER + 1);
        triggerstartpos = linepos[sidx]; if (!triggerstartpos) triggerstartpos = buf;
        triggerlinecount = LINES_AROUND_TRIGGER;
      }
    }

And line 963:

    switch (walk->checktype) {
      case C_LOG:
      data = logdata(walk->filename, &walk->check.logcheck); ← line 963
      fprintf(stdout, "[msgs:%s]\n", walk->filename);
      fprintf(stdout, "%s\n", data);


Triggers used (piped through cat –vet):

trigger ERROR$
trigger Error|Segmentation$
trigger Error|Segmentation$
trigger ChannelClosedException|ORA.|Memory|ERROR|FATAL|SQLException|ClassCircularityError|did not respond|CORBA TIMEOUT$
trigger ChannelClosedException|ORA.|Memory|ERROR|FATAL|SQLException|ClassCircularityError|did not respond|CORBA TIMEOUT$
trigger Memory|ERROR|FATAL|ClassCircularityError|did not respond|CORBA TIMEOUT$
trigger ERROR|FATAL|SQLException|(ORA\-)|OutOfMemoryError$
trigger ERROR|FATAL|SQLException|(ORA\-)|OutOfMemoryError$

~David


-----Original Message-----
From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au] 
Sent: Thursday, December 15, 2011 20:47
To: Gore, David W (David)
Cc: xymon at xymon.com
Subject: Re: [Xymon] logfetch bug or trigger syntax in client-local.cfg?

2011/12/15 Gore, David W (David) <david.gore at verizon.com>:
> We are receiving core dumps of logfetch at irregular times but it is quite persistent.  This is mostly on SunOS 10 SPARC clients with a 4.3.6 Xymon client build.

> #2  0x00014730 in main (argc=1, argv=0x36000) at logfetch.c:963

On 25th August, I reported to the List (what appears to be) this exact
same problem.  My systems are SUSE Linux running Xymon 4.3.3, but I
also confirmed the problem with 4.3.4.  As I reported then, I can
sometimes work around the problem by increasing maxbytes to larger
than the logfile size.  More reliably, if I don't use "ignore", it
doesn't dump core.  So that's what I'm doing now.

Cheers
Jeremy