Fix handling of timers when cloning TableVals

When cloning TableVals, a new timer was created for the wrong object
(the existing TableVal, not the clone). This lead to the already
existing timer being no longer accessible. Which, in turn, leads to an
abandoned timer reading into no longer allocated data when the original
TableVal is deleted.

Fixes GH-1687
This commit is contained in:
Johanna Amann 2021-07-21 12:52:22 +01:00
parent c58e4ec445
commit 13cfa4c938
2 changed files with 8 additions and 2 deletions

View file

@ -2768,8 +2768,8 @@ ValPtr TableVal::DoClone(CloneState* state)
// As network_time is not necessarily initialized yet, we set // As network_time is not necessarily initialized yet, we set
// a timer which fires immediately. // a timer which fires immediately.
timer = new TableValTimer(this, 1); tv->timer = new TableValTimer(tv.get(), 1);
detail::timer_mgr->Add(timer); detail::timer_mgr->Add(tv->timer);
} }
if ( expire_func ) if ( expire_func )

View file

@ -35,3 +35,9 @@ event zeek_init() &priority=-10
data[0] = "some data"; data[0] = "some data";
schedule 4sec { do_it() }; schedule 4sec { do_it() };
} }
# Test that re-defing a table with an expiry in a specific way
# does not crash Zeek; see GH-1687.
global hosts: set[addr] &create_expire=1day &redef;
redef hosts: set[addr] = {};