[Xymon] logfetch segfault using deltacount after a find command... and deltacount always returns 0 when no segfault

[SebA]

It seems that when using deltacount after a log statement with a 'find' in
it like in the example below causes a seg fault in logfetch:

log:`find /opt/tomcat/logs/myapp.$(date +%F).log`:10240
# deltacount after a find causes a seg fault.
deltacount WarningDeltaCount "WARNING"

It does not seem to matter if the find statement is actually in a different
higher up log line that should not be affecting this deltacount.  The
workaround to that is to re-order the log statements such that your find is
below the deltacount, but that still means they can not be used together,
which means we can not use deltacount in the example above.

This core backtrace does not look very helpful to me, but maybe because I
am using a non-debug version of the 4.3.28 xymon-client RPM (
https://terabithia.org/rpms/xymon/el6/x86_64/xymon-client-4.3.28-1.el6.x86_64.rpm
):

core_backtrace:
:{   "signal": 11
:,   "executable": "/usr/bin/logfetch"
:,   "stacktrace":
:      [ {   "crash_thread": true
:        ,   "frames":
:              [ {   "address": 4217378
:                ,   "build_id": "40398b05a94e8227d573537651e7f595e5ef0d96"
:                ,   "build_id_offset": 23074
:                ,   "file_name": "/usr/bin/logfetch"
:                } ]
:        } ]
:}

It was the same on 4.3.26-1 RPM.

*Separately*, I believe that even when there is no segfault (because I hard
code the filename), and the clientlog is all present and correct, that
deltacount actually returns the wrong number of lines - it always seems to
be 0 in my tests (with --debug, run from command line):

550 2017-11-14 13:12:38.042701 logfetch: -> logdata
(/opt/tomcat/logs/myapp.2017-11-14.log)
550 2017-11-14 13:12:38.043112  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 0, loc 2558853
550 2017-11-14 13:12:38.043133  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 1, loc 2557130
550 2017-11-14 13:12:38.043149  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 2, loc 0
550 2017-11-14 13:12:38.043181  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 3, loc 0
550 2017-11-14 13:12:38.043199  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 4, loc 0
550 2017-11-14 13:12:38.043224  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 5, loc 0
550 2017-11-14 13:12:38.043240  - fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 6, loc 0
550 2017-11-14 13:12:38.043274 logfetch: Current size (ending): 2560538
bytes. Last end was 2558853. Looking 6 spots before that, which is 0.
bytestocurrent: 2558853
550 2017-11-14 13:12:38.043322  - compiling DELTACOUNT regex: "WARNING"
550 2017-11-14 13:12:38.064073  - Last position was 2558853, found curpos
location at 2558853 in current buffer.
550 2017-11-14 13:12:38.064121  - line forced as a trigger: <...CURRENT...>
14-Nov-2017 13:11:09.259 FINE [pool-1-thread-6923] [edited out]
550 2017-11-14 13:12:38.064135  - first trigger line encountered; preparing
trigger START & END positioning store
550 2017-11-14 13:12:38.064146  - new trigger anchor START position set
550 2017-11-14 13:12:38.064164  - trigger END position set
550 2017-11-14 13:12:38.064194 Marked 1 pairs of START and END anchors for
consideration.
550 2017-11-14 13:12:38.064206 Found 1674 bytes of trigger data, 8566 bytes
available space for non-trigger data; last trigger ended 961 bytes from
end. Max bytes allowed is 10240.
550 2017-11-14 13:12:38.064222 Staging replacement buffer, 10272 bytes.
550 2017-11-14 13:12:38.064233 Copying buffer content for trigger 1.
550 2017-11-14 13:12:38.064247 logfetch: More space was available than
between last trigger and eof; reducing to 961 bytes
550 2017-11-14 13:12:38.064259 logfetch: Delta from end of final trigger to
beginning of final section: 0 bytes
550 2017-11-14 13:12:38.064268 Copying 961 final bytes of non-trigger
content
550 2017-11-14 13:12:38.064351  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 0, loc 2560538
550 2017-11-14 13:12:38.064362  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 1, loc 2558853
550 2017-11-14 13:12:38.064372  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 2, loc 2557130
550 2017-11-14 13:12:38.064382  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 3, loc 0
550 2017-11-14 13:12:38.064394  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 4, loc 0
550 2017-11-14 13:12:38.064403  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 5, loc 0
550 2017-11-14 13:12:38.064413  -- fn:
/opt/tomcat/logs/myapp.2017-11-14.log, pos 6, loc 0
550 2017-11-14 13:12:38.064424 logfetch: <- logdata
(/opt/tomcat/logs/myapp.2017-11-14.log)
[msgs:/opt/tomcat/logs/myapp.2017-11-14.log]

Can anyone help?  Thanks,

SebA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20171114/110e486f/attachment.html>