&expire_func/&create_expire question

Hi,

can the &expire_func and &create_expire attributes be assigned at
run-time? Mike (cc'd) sent me code for a sliding window implementation,
which contained this:

function sw_new( window : interval ) : sliding_window {
    local w : sliding_window;
    local tbl : table[time] of __sliding_window_slot
  &create_expire=window &expire_func=__sw_expire_slot;
    [...]

The parser accepts this without complaint but the code caused a
segmentation fault ...

Program received signal SIGSEGV, Segmentation fault.
0x0812c31a in Val::AsInterval (this=0x0) at Val.h:247
247 CONST_ACCESSOR(TYPE_INTERVAL, double, double_val, AsInterval)
(gdb) bt
#0 0x0812c31a in Val::AsInterval (this=0x0) at Val.h:247
#1 0x0820a890 in TableVal::CheckExpireAttr (this=0x84148e8, at=ATTR_EXPIRE_CREATE) at Val.cc:1746
#2 0x0820a964 in TableVal::SetAttrs (this=0x84148e8, a=0x8302318) at Val.cc:1733
#3 0x082166d1 in TableVal (this=0x84148e8, t=0x83039f0, a=0x8302318) at Val.cc:1680
#4 0x081d7c94 in InitStmt::Exec (this=0x8304870, f=0x8413170, flow=@0xbf93ad2c) at Stmt.cc:1608
#5 0x081d7edd in StmtList::Exec (this=0x83047c8, f=0x8413170, flow=@0xbf93ad2c) at Stmt.cc:1390
#6 0x081460d8 in BroFunc::Call (this=0x8304750, args=0x84147a0, parent=0x84131a8) at Func.cc:313

... that went away by making the window size fixed:

type slots_table: table[time] of __sliding_window_slot
  &create_expire=SLIDING_WINDOW &expire_func=__sw_expire_slot;

function sw_new() : sliding_window {
    local w : sliding_window;
    local tbl : slots_table;

Cheers,
Christian.

can the &expire_func and &create_expire attributes be assigned at
run-time?

They should be, and looking at the code in question where you're getting
the crash, I don't offhand see why it's failing. Can you or Mike put
together a self-contained demo script that tickles this bug?

    Vern

Here you go -- this crashes on the first packet:

Here you go -- this crashes on the first packet:

Thanks. That indeed reproduces the problem for me.

    Vern

Ok, found the problem: it's not possbile to give *local* variables
as the timeout; constants and globals are fine. I'm going to add an
error message for the case of locals.

Robin

Ok, found the problem: it's not possbile to give *local* variables
as the timeout; constants and globals are fine. I'm going to add an
error message for the case of locals.

This doesn't seem to me to be the correct semantics. It's a local variable
that's being created. It should set its expiration timeout based on the
value of the expression used in the declaration. It doesn't matter that
that expression is in terms of a local variable, provided that that variable
is defined at the time of initialization - which is indeed the case in the
example Christian put together.

    Vern

Well, I agree. I would also like to see it work.

I suppose my mail was misleading: it's not for semantical reasons
that it doesn't work but for technical. At the location inside the
code where the expire expression is evaluated (inside TableVal), I
don't have a Frame at hand to access local variables. I haven't
checked whether we might be able to get the Frame information to
that place in some way but even if we could, it wouldn't exactly
make the code nicer ...

Robin