Bug 1078878

Also affects rsyslog-7.4.7-5.el7.


+++ This bug was initially created as a clone of Bug #996862 +++

Description of problem:

When second operand becomes zero in configuration has division/modulus, rsyslog crashes by 'Floating point exception'


Version-Release number of selected component (if applicable):
v5.8.10


How reproducible:
have a configuration like

if 100 % $msgid == 0 then /var/log/event.log

and (re)start rsyslog


Additional info:
below is the bracktrace


[root@localhost etc]# gdb rsyslogd
(gdb) r -nd
Starting program: /sbin/rsyslogd -nd
[Thread debugging using libthread_db enabled]

<...>

8780.491765709:7ffff7f8d700: MsgSetTAG in: len 9, pszBuf: rsyslogd:
8780.491768746:7ffff7f8d700: MsgSetTAG exit: pMsg->iLenTAG 9, pMsg->TAG.szBuf: rsyslogd:
8780.491777641:7ffff6735700: we deleted 0 objects and enqueued 0 objects
8780.491782073:7ffff6735700: delete batch from store, new sizes: log 1, phys 1
8780.491790598:7ffff6735700: processBatch: batch of 1 elements must be processed
8780.491793557:7ffff6735700: Processing next rule
8780.491816338:7ffff6735700: rainerscript: executing step, opcode 1002...
8780.491819931:7ffff6735700: rainerscript: opcode PUSHMSGVAR
8780.491827350:7ffff6735700: rainerscript: executing step, opcode 1003...
8780.491830086:7ffff6735700: rainerscript: opcode PUSHCONSTANT
8780.491832906:7ffff6735700: rainerscript: executing step, opcode 6...
8780.491835520:7ffff6735700: rainerscript: opcode DIV

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffff6735700 (LWP 2024)]
0x00007ffff7fd5a4b in opDIV (pThis=0x7ffff00008c0, pProg=<value optimized out>) at vm.c:245
245	NUMOP(DIV,    /)
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x00007ffff7fd5a4b in opDIV (pThis=0x7ffff00008c0, pProg=<value optimized out>) at vm.c:245
#1  execProg (pThis=0x7ffff00008c0, pProg=<value optimized out>) at vm.c:704
#2  0x00007ffff7fdcbac in shouldProcessThisMessage (pThis=0x7ffff82190f0, pBatch=0x7ffff822f658) at rule.c:184
#3  processBatch (pThis=0x7ffff82190f0, pBatch=0x7ffff822f658) at rule.c:275
#4  0x00007ffff7fdb9ae in processBatchDoRules (pData=0x7ffff82190f0, pParam=0x7ffff822f658) at ruleset.c:150
#5  0x00007ffff7fc67ff in llExecFunc (pThis=0x7ffff82166b0, pFunc=0x7ffff7fdb980 <processBatchDoRules>, pParam=0x7ffff822f658) at linkedlist.c:389
#6  0x00007ffff7fdbed6 in processBatch (pBatch=0x7ffff822f658) at ruleset.c:232
#7  0x00007ffff7fb39b1 in msgConsumer (notNeeded=<value optimized out>, pBatch=0x7ffff822f658, pbShutdownImmediate=0x7ffff821b988) at syslogd.c:703
#8  0x00007ffff7fdb5ad in ConsumerReg (pThis=0x7ffff821b970, pWti=0x7ffff822f630) at queue.c:1705
#9  0x00007ffff7fd4046 in wtiWorker (pThis=0x7ffff822f630) at wti.c:313
#10 0x00007ffff7fd3b3a in wtpWorker (arg=0x7ffff822f630) at wtp.c:387
#11 0x00007ffff7958851 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff708490d in clone () from /lib64/libc.so.6


--- Additional comment from Tomas Heinrich on 2013-11-15 11:03:50 CET ---

I've tested the patch and it looks good.

Sorry for the long delay in reviewing it.