Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)

[fosstrack]

from pprint import pprint
from durable.lang import *

with ruleset('metrics'):
    @when_all(  # distinct(True),
        c.first << (m.metric == 'met-A') & (m.amount > 10),
        c.second << (m.metric == 'met-B') & (m.amount > c.first.amount)
    )
    def detected(c):
        pprint(vars(c))
        print('detected--1    -> {0}'.format(c.first.amount))
        print('               -> {0}'.format(c.second.amount))


    @when_all(  # distinct(True),
        c.first << (m.metric == 'met-A') & (m.amount > 50),
        c.second << (m.metric == 'met-B') & (m.amount < c.first.amount)
    )
    def detected2(c):
        pprint(vars(c))
        print('detected--2 -> {0}'.format(c.first.amount))
        print('            -> {0}'.format(c.second.amount))

# Works: Calls detected2() and print detected --2. No errors.
# post('metrics', { 'sid': 1, 'metric': 'met-A', 'amount': 250})
# post('metrics', { 'sid': 1, 'metric': 'met-B',  'amount': 200})

# Crash: Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
# Expected to run detected()
post('metrics', { 'metric': 'met-A', 'amount': 100})
post('metrics', { 'metric': 'met-B', 'amount': 200})

[fosstrack]

If I switch the order of the rules in the file, I don't get the error. Seems like a conflict between the 2 rules, but I cannot figure it out.

[fosstrack]

Running gdb on the core dump:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.8.5 (default, Sep  4 2020, 07:30:14)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import crash1
[New Thread 0x7ffff6fd6700 (LWP 1314782)]
[New Thread 0x7ffff67d5700 (LWP 1314783)]

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff70dd3ad in reduceExpressionSequence (tree=0x555555a39050, state=0x555555a3d1a8, exprs=0x555555a4b978, operator=12,
    messageObject=<optimized out>, context=<optimized out>, i=0x7fffffffa26a, targetProperty=0x7fffffffa290) at src/rules/events.c:616
616                     currentExpression = &exprs->expressions[*i];

I have similar test cases that use sequences within rulesets that report the error at the exact same location (src/rules/events.c:616)