# Hitting Error Dictionary insertion distance too far: 65535

**URL:** <https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978>\
**Category:** Zeek\
**Tags:** development\
**Created:** [May 1, 2026, 9:47am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978 "2026-05-01T09:47:34Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [May 1, 2026, 9:47am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/1 "2026-05-01T09:47:34Z")

</div>

Hello everyone,

I’m new to Zeek, and I’m trying to process large pcap files using `zeek -r <pcap>`. Currently, since my pcap file too large to process in one run, I’m using editcap to split them into manageable chunks that are a few gigabytes each. However, when I run Zeek, I get this specific error:

- Dictionary (size 30158043) insertion distance too far: 65535

I haven’t changed the default configurations for Zeek, and this seems like an internal hash table issue in the C++ code. I read through the Zeek changelog and found this comment for version `4.1.0-dev.554`:

```auto
When choosing poor/aggressive values for `table_expire_interval`,
    `table_expire_delay`, and/or `table_incremental_step` that tend to
    leave tables in state of constant table-expiry-iteration, the underlying
    Dictionary is never allowed the chance to complete remapping operations
    which re-position entries to more ideal locations (e.g. after
    reallocating the table to be able to store more entries).

```

I haven’t changed any of the values for the above mentioned variables, so I’m curious what I can do to mitigate or resolve this error and get a little more background on it, or if I have to adjust my approach/settings. Any help to understand/resolve this issue better would be very much appreciated!

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [May 4, 2026, 9:14am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/2 "2026-05-04T09:14:17Z")

</div>

Hey @rachit - thanks a lot for the report. Are you able to reliably reproduce this?

That message/crash should produce a coredump. Are you in a position to run gdb on it and could share a backtrace?

```auto
(gdb) bt -full

```

Remove the `-full` if it’s too much data, or sanitize if it looks like it contains sensitive data. The `-full` flag might help to grasp what’s going on better.

~30 mio entries is fairly large. Maybe the backtrace allows to figure out which table is involved. It shouldn’t ever result in an abort like that though.

If you’re on Ubuntu/Debian/Fedora Linux, easiest these days is probably to install `systemd-coredump`, run your pipeline to the crash, then `coredumpctl list` + `coredumpctl debug` to work with the coredumps.

Curious what you’ll report!

Here’s a link from a while back - mostly for reference: [copy() of table with 10mio (and 5.0mio and 2.3mio) entries: fatal error: Dictionary (size 1452082) insertion distance too far: 65535 · Issue #2386 · zeek/zeek · GitHub](https://github.com/zeek/zeek/issues/2386)

---

<div class="post-metadata">

**Author:** ![Benjamin\_Bannier](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/benjamin_bannier/32/595_2.png) [@Benjamin\_Bannier](https://community.zeek.org/u/Benjamin_Bannier)\
**Post date:** [May 4, 2026, 10:00am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/3 "2026-05-04T10:00:39Z")

</div>

While trying to repro this I ran into a [probably orthogonal issue](https://github.com/zeek/zeek/pull/5428).

> ****
>
> Possibly related, there seem to be issues when dictionaries grow large.
> 
> ```auto
> event zeek_init()
> {
> local xs: table[count] of count;
> 
> local i = 0;
> while ( i < 100000000 )
> {
> xs[i] = i;
> ++i;
> }
> }
> 
> ```
> 
> For me eventually this fails in a Debug build with
> 
> ```auto
> 32786296
> 32786297
> 32786298
> 32786299
> 
> Thread 1 "zeek" received signal SIGSEGV, Segmentation fault.
> zeek::detail::DictEntry<zeek::TableEntryVal>::Empty (this=0x8000003c0) at /root/src/zeek/src/include/zeek/Dict.h:130
> 130 bool Empty() const { return distance == TOO_FAR_TO_REACH; }
> 
> ```
> 
> Interestingly, memory usage seems to go up slowly at first, but quickly shoots up towards the end.
> 
> ```auto
> #0 zeek::detail::DictEntry<zeek::TableEntryVal>::Empty (this=0x8000003c0) at /root/src/zeek/src/include/zeek/Dict.h:130
> No locals.
> #1 0x0000555557e4a762 in zeek::Dictionary<zeek::TableEntryVal>::Remap (this=0x555559df80d0) at /root/src/zeek/src/include/zeek/Dict.h:1370
> left = 16
> #2 0x0000555557e4a30d in zeek::Dictionary<zeek::TableEntryVal>::Insert (this=0x555559df80d0, key=0x5555f6e62e20, key_size=8, hash=12684133978465182291, val=0x5555f6e62d80, copy_key=false, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/include/zeek/Dict.h:647
> v = 0x0
> insert_position = 18220270
> insert_distance = 31
> position = -1
> #3 0x0000555557e31556 in zeek::Dictionary<zeek::TableEntryVal>::Insert (this=0x555559df80d0, key=0x55555a529750, val=0x5555f6e62d80, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/include/zeek/Dict.h:549
> No locals.
> #4 0x0000555557e1d942 in zeek::TableVal::Assign (this=0x555559df8b40, index=..., k=std::unique_ptr<zeek::detail::HashKey> = {...}, new_val=..., broker_forward=true, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/Val.cc:1834
> is_set = false
> new_entry_val = 0x5555f6e62d80
> k_copy = {key_u = {b = 240, i = -21008, bi = 140737488334320, bu = 140737488334320, u32 = 4294946288, d = 6.9533558067970712e-310, p = 0x7fffffffadf0}, key = 0x5555f6e62dd0 "{G\364\001", hash = 12684133978465182291, key_size = 8, is_our_dynamic = true, write_size = 8, read_size = 0}
> old_entry_val = 0x5555f6e62df0
> #5 0x0000555557e1a6ce in zeek::TableVal::Assign (this=0x555559df8b40, index=..., new_val=..., broker_forward=true, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/Val.cc:1822
> k = std::unique_ptr<zeek::detail::HashKey> = {get() = 0x0}
> #6 0x0000555557c995ec in zeek::detail::assign_to_index (v1=..., v2=..., v3=..., iterators_invalidated=@0x7fffffffb387: false) at /root/src/zeek/src/Expr.cc:320
> v_extra = {ptr_ = 0x5555f6e62df0}
> #7 0x0000555557c98cd0 in zeek::detail::Expr::AssignToIndex (this=0x55555a2956d0, v1=..., v2=..., v3=...) at /root/src/zeek/src/Expr.cc:248
> iterators_invalidated = false
> error_msg = 0x5555f6e62df0 "p\245sXUU"
> #8 0x0000555557cac4f9 in zeek::detail::IndexExpr::Assign (this=0x55555a2956d0, f=0x7fffffffbb40, v=...) at /root/src/zeek/src/Expr.cc:2784
> v1 = {ptr_ = 0x555559df8b40}
> v2 = {ptr_ = 0x555559df7db0}
> #9 0x0000555557ca8317 in zeek::detail::RefExpr::Assign (this=0x55555a295850, f=0x7fffffffbb40, v=...) at /root/src/zeek/src/Expr.cc:2267
> No locals.
> #10 0x0000555557ca99e5 in zeek::detail::AssignExpr::Eval (this=0x55555a295800, f=0x7fffffffbb40) at /root/src/zeek/src/Expr.cc:2442
> v = {ptr_ = 0x5555f6e62df0}
> #11 0x0000555557dcd5f5 in zeek::detail::ExprStmt::Exec (this=0x55555a295930, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:380
> v = {ptr_ = 0x5555576f44d9 <_ZN9 __gnu_cxxeqIPN4zeek12IntrusivePtrINS1_6detail4StmtEEESt6vectorIS5_SaIS5_EEEEbRKNS_17__ normal_iteratorIT_T0_EESF_QrqXeqcldtfp_4baseEcldtfp0_4baseERSt14convertible_toIbEE+41>}
> #12 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x55555a295060, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x55555a295930
> result = {ptr_ = 0x0}
> stmt_ptr = @0x55555a29be98: {ptr_ = 0x55555a295930}
> __range2 = std::vector of length 3, capacity 4 = {{ptr_ = 0x55555a295350}, {ptr_ = 0x55555a295930}, {ptr_ = 0x55555a295b60}}
> __begin2 = {ptr_ = 0x55555a295930}
> __end2 = {ptr_ = 0x7963696c6f}
> #13 0x0000555557dd15fd in zeek::detail::WhileStmt::Exec (this=0x55555a295c10, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1000
> cond = {ptr_ = 0x55555888def0}
> rval = {ptr_ = 0x0}
> #14 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x5555595427a0, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x55555a295c10
> result = {ptr_ = 0x0}
> stmt_ptr = @0x555559541da0: {ptr_ = 0x55555a295c10}
> __range2 = std::vector of length 3, capacity 4 = {{ptr_ = 0x555559542620}, {ptr_ = 0x55555a294e10}, {ptr_ = 0x55555a295c10}}
> __begin2 = {ptr_ = 0x55555a295c10}
> __end2 = {ptr_ = 0x0}
> #15 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x55555a295cf0, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x5555595427a0
> result = {ptr_ = 0x0}
> stmt_ptr = @0x55555a295e78: {ptr_ = 0x5555595427a0}
> Quit
> #0 zeek::detail::DictEntry<zeek::TableEntryVal>::Empty (this=0x8000003c0) at /root/src/zeek/src/include/zeek/Dict.h:130
> No locals.
> #1 0x0000555557e4a762 in zeek::Dictionary<zeek::TableEntryVal>::Remap (this=0x555559df80d0) at /root/src/zeek/src/include/zeek/Dict.h:1370
> left = 16
> #2 0x0000555557e4a30d in zeek::Dictionary<zeek::TableEntryVal>::Insert (this=0x555559df80d0, key=0x5555f6e62e20, key_size=8, hash=12684133978465182291, val=0x5555f6e62d80, copy_key=false, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/include/zeek/Dict.h:647
> v = 0x0
> insert_position = 18220270
> insert_distance = 31
> position = -1
> #3 0x0000555557e31556 in zeek::Dictionary<zeek::TableEntryVal>::Insert (this=0x555559df80d0, key=0x55555a529750, val=0x5555f6e62d80, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/include/zeek/Dict.h:549
> No locals.
> #4 0x0000555557e1d942 in zeek::TableVal::Assign (this=0x555559df8b40, index=..., k=std::unique_ptr<zeek::detail::HashKey> = {...}, new_val=..., broker_forward=true, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/Val.cc:1834
> is_set = false
> new_entry_val = 0x5555f6e62d80
> k_copy = {key_u = {b = 240, i = -21008, bi = 140737488334320, bu = 140737488334320, u32 = 4294946288, d = 6.9533558067970712e-310, p = 0x7fffffffadf0}, key = 0x5555f6e62dd0 "{G\364\001", hash = 12684133978465182291, key_size = 8, is_our_dynamic = true, write_size = 8, read_size = 0}
> old_entry_val = 0x5555f6e62df0
> #5 0x0000555557e1a6ce in zeek::TableVal::Assign (this=0x555559df8b40, index=..., new_val=..., broker_forward=true, iterators_invalidated=0x7fffffffb387) at /root/src/zeek/src/Val.cc:1822
> k = std::unique_ptr<zeek::detail::HashKey> = {get() = 0x0}
> #6 0x0000555557c995ec in zeek::detail::assign_to_index (v1=..., v2=..., v3=..., iterators_invalidated=@0x7fffffffb387: false) at /root/src/zeek/src/Expr.cc:320
> v_extra = {ptr_ = 0x5555f6e62df0}
> #7 0x0000555557c98cd0 in zeek::detail::Expr::AssignToIndex (this=0x55555a2956d0, v1=..., v2=..., v3=...) at /root/src/zeek/src/Expr.cc:248
> iterators_invalidated = false
> error_msg = 0x5555f6e62df0 "p\245sXUU"
> #8 0x0000555557cac4f9 in zeek::detail::IndexExpr::Assign (this=0x55555a2956d0, f=0x7fffffffbb40, v=...) at /root/src/zeek/src/Expr.cc:2784
> v1 = {ptr_ = 0x555559df8b40}
> v2 = {ptr_ = 0x555559df7db0}
> #9 0x0000555557ca8317 in zeek::detail::RefExpr::Assign (this=0x55555a295850, f=0x7fffffffbb40, v=...) at /root/src/zeek/src/Expr.cc:2267
> No locals.
> #10 0x0000555557ca99e5 in zeek::detail::AssignExpr::Eval (this=0x55555a295800, f=0x7fffffffbb40) at /root/src/zeek/src/Expr.cc:2442
> v = {ptr_ = 0x5555f6e62df0}
> #11 0x0000555557dcd5f5 in zeek::detail::ExprStmt::Exec (this=0x55555a295930, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:380
> v = {ptr_ = 0x5555576f44d9 <_ZN9 __gnu_cxxeqIPN4zeek12IntrusivePtrINS1_6detail4StmtEEESt6vectorIS5_SaIS5_EEEEbRKNS_17__ normal_iteratorIT_T0_EESF_QrqXeqcldtfp_4baseEcldtfp0_4baseERSt14convertible_toIbEE+41>}
> #12 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x55555a295060, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x55555a295930
> result = {ptr_ = 0x0}
> stmt_ptr = @0x55555a29be98: {ptr_ = 0x55555a295930}
> __range2 = std::vector of length 3, capacity 4 = {{ptr_ = 0x55555a295350}, {ptr_ = 0x55555a295930}, {ptr_ = 0x55555a295b60}}
> __begin2 = {ptr_ = 0x55555a295930}
> __end2 = {ptr_ = 0x7963696c6f}
> #13 0x0000555557dd15fd in zeek::detail::WhileStmt::Exec (this=0x55555a295c10, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1000
> cond = {ptr_ = 0x55555888def0}
> rval = {ptr_ = 0x0}
> #14 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x5555595427a0, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x55555a295c10
> result = {ptr_ = 0x0}
> stmt_ptr = @0x555559541da0: {ptr_ = 0x55555a295c10}
> __range2 = std::vector of length 3, capacity 4 = {{ptr_ = 0x555559542620}, {ptr_ = 0x55555a294e10}, {ptr_ = 0x55555a295c10}}
> __begin2 = {ptr_ = 0x55555a295c10}
> __end2 = {ptr_ = 0x0}
> #15 0x0000555557dd466d in zeek::detail::StmtList::Exec (this=0x55555a295cf0, f=0x7fffffffbb40, flow=@0x7fffffffba5f: zeek::detail::FLOW_NEXT) at /root/src/zeek/src/Stmt.cc:1426
> stmt = 0x5555595427a0
> result = {ptr_ = 0x0}
> stmt_ptr = @0x55555a295e78: {ptr_ = 0x5555595427a0}
> Quit
> Continuing.
> Couldn't get registers: No such process.
> [Thread 0x7fffe1ffb6c0 (LWP 11554) exited]
> [Thread 0x7fffe27fc6c0 (LWP 11553) exited]
> [Thread 0x7fffe2ffd6c0 (LWP 11552) exited]
> [Thread 0x7fffe37fe6c0 (LWP 11551) exited]
> [Thread 0x7fffe3fff6c0 (LWP 11550) exited]
> [Thread 0x7ffff08f66c0 (LWP 11549) exited]
> [Thread 0x7ffff10f76c0 (LWP 11548) exited]
> [Thread 0x7ffff18f86c0 (LWP 11547) exited]
> [Thread 0x7ffff29ff6c0 (LWP 11546) exited]
> Quit
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> Quit
> quit
> 
> ```

---

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [May 6, 2026, 8:28am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/4 "2026-05-06T08:28:37Z")

</div>

Hi @awelzel,

I don’t think I’m currently in a position to run gdb and perform a backtrace. I’m running this on a HPC, currently takes about ~3 hours to split the pcap I am trying to process into smaller pcaps, which are approx. ~380 gb in size and processed for another ~1.5 hours before crashing. I’m thinking it may be an issue where there is too much data to process.

---

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [May 6, 2026, 8:32am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/5 "2026-05-06T08:32:22Z")

</div>

It seems to consistently fail after 30 million entries, I believe I could have more data than that in each of my files.

---

<div class="post-metadata">

**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\
**Post date:** [May 6, 2026, 7:23pm UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/6 "2026-05-06T19:23:09Z")

</div>

I’m curious which table this is about. I’m attaching a script below that introduces a new log that periodically reports the “footprints” (i.e., approximate sizes) of global containers in the script layer. You could try that one and see if one works its way up to those ~30M entries.

(Btw, I think we should get that log/script into the Zeek tree — we’ve been handing that out somewhat regularly.)

[footprints.zeek.gz](https://community.zeek.org/uploads/short-url/8oNpqL70pLUAOP1Jb0nOHbvd34S.gz) (615 Bytes)

---

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [May 15, 2026, 5:21pm UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/7 "2026-05-15T17:21:35Z")

</div>

I ran the footprints.zeek on my pcap and what’s interesting is that I don’t see a table that goes all the way up to 30M entries. I’ve uploaded the file here in case anyone is able to spot and see an issue, but this is puzzling. The max table size I’m seeing is ~18000 items, so now I’m a little confused.

[footprints.log.zip](https://community.zeek.org/uploads/short-url/tPHXJwIP14ParhCwMC1aGf40fzq.zip) (4.1 KB) Expanded: 15KB

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [May 17, 2026, 1:31pm UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/8 "2026-05-17T13:31:53Z")

</div>

> The max table size I’m seeing is ~18000 items

This is actually the footprint, not the number of entries. Can be a bit confusing. The highest values are all from const tables that aren’t expected to grow at runtime.

```auto
1747313999.999999 zeek SSL::cipher_desc 1920
1747313999.999999 zeek SSL::root_certs 5553
1747313999.999999 zeek SMB::statuses 17282
1747313999.999999 zeek DCE_RPC::operations 17998

```

It is very likely that it is a table/set that is attached to a particular connection instead. There is a [zeek-conn-footprint](https://github.com/awelzel/zeek-conn-footprint) package that produces a `conn_footprint.log` for tracking the size/state attached to individual connections. Could you install this one and see if any particular connections shows as very large. I’m fairly sure a 30M table entry attached to a connection will be visible. Would be interesting which protocol is involved, etc to possibly make a reproducer easier.

---

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [June 1, 2026, 8:22am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/9 "2026-06-01T08:22:09Z")

</div>

I downloaded and reran my analysis script with the package, but I wasn’t able to find a `conn_footprint.log` in my output… could it be that it wasn’t sampling fast enough?

```auto
[Fri May 29 04:37:27 PDT 2026] Installing zeek-conn-footprint...
Installing "https://github.com/awelzel/zeek-conn-footprint.git"
Installed "https://github.com/awelzel/zeek-conn-footprint.git" (v0.2.1)
Loaded "https://github.com/awelzel/zeek-conn-footprint.git"
[Fri May 29 04:37:30 PDT 2026] zkg done, installed files:
/<path>/zeek-site/packages/zeek-conn-footprint.git/main.zeek
/<path>/zeek-site/packages/zeek-conn-footprint.git/ __load__.zeek
/<path>/zeek-site/packages/packages.zeek
/<path>/zeek-site/packages/ __load__.zeek
[Fri May 29 04:37:31 PDT 2026] Splitting <pcap>.pcap into 300s chunks...
[Fri May 29 05:09:12 PDT 2026] Found 1 chunks.
[Fri May 29 05:09:12 PDT 2026] Running Zeek on chunk_00000_<pcap>...
1747314039.323292 fatal error: Dictionary (size 29273515) insertion distance too far: 65535
/scratch/split_and_zeek.sh: line 24: 3577145 Aborted (core dumped) zeek -r "${chunk}" /footprints.zeek # footprints.zeek has the include for the package
[Fri May 29 08:01:26 PDT 2026] Cleaning up scratch...
[Fri May 29 08:01:41 PDT 2026] Done. Results in /output.

```

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [June 1, 2026, 8:34am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/10 "2026-06-01T08:34:42Z")

</div>

> in my output… could it be that it wasn’t sampling fast enough?

Hmm, it should be based on network time / pcap time and so it should work out if there’s something to report.

> (core dumped) zeek -r “${chunk}” /footprints.zeek # footprints.zeek has the include for the package

Do you get a log if you put `packages` or `zeek-conn-footprint` after the `/footprints.zeek`arg on the command-line. When you install packages with `zkg` in a default Zeek environment, they are not loaded by default when invoking `zeek` or even `zeek local`. It’s a bit of a quirk. One needs to pass `packages` or the concrete package name explicit to the `zeek` invocation.

---

<div class="post-metadata">

**Author:** ![rachit](https://avatars.discourse-cdn.com/v4/letter/r/91b2a8/32.png) [@rachit](https://community.zeek.org/u/rachit)\
**Post date:** [June 18, 2026, 7:36am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/11 "2026-06-18T07:36:18Z")

</div>

Hmm, I think I’ve fixed the problem, I’m almost positive I’m doing it correctly but I still don’t think I can find a `conn_footprint.log` file:

```auto
[Thu Jun 18 00:26:29 PDT 2026] Installing zeek-conn-footprint...
Installing "https://github.com/awelzel/zeek-conn-footprint"
Installed "https://github.com/awelzel/zeek-conn-footprint" (v0.2.1)
Loaded "https://github.com/awelzel/zeek-conn-footprint"
[Thu Jun 18 00:26:32 PDT 2026] zkg done, installed files:
/scratch/rjaiswal/job_51060178/zeek-site/packages/zeek-conn-footprint/ __load__.zeek
/scratch/rjaiswal/job_51060178/zeek-site/packages/zeek-conn-footprint/main.zeek
/scratch/rjaiswal/job_51060178/zeek-site/packages/ __load__.zeek
/scratch/rjaiswal/job_51060178/zeek-site/packages/packages.zeek
[Thu Jun 18 00:26:32 PDT 2026] Splitting truncated_2gb.pcap into 300s chunks...
[Thu Jun 18 00:26:32 PDT 2026] Found 1 chunks.
[Thu Jun 18 00:26:32 PDT 2026] Running Zeek on chunk_00000_20251120050000...
[Thu Jun 18 00:26:35 PDT 2026] Cleaning up scratch...
[Thu Jun 18 00:26:35 PDT 2026] Done. Results in /output.

```

_I split into 300s intervals, but I’m running on a smaller test pcap so it only splits it into one chunk_

I’m finding different footprint..log files and packet\_filter..log files, and I’m not quite sure what’s going on. I’m positive the package is running though, because it was erroring before when it couldn’t find the packages when I added `packages` to the command but I fixed some environment variables and got it to work. Now, I’m not sure what’s happening and why its silently failing.

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [June 19, 2026, 7:51am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/12 "2026-06-19T07:51:45Z")

</div>

Hello @rachit ,

> Now, I’m not sure what’s happening and why its silently failing.

Do you have `misc/loaded-scripts`loaded? It should produce a `loaded_scripts.log` and you can verify within that log, that the conn footprint package and script was loaded.

If it has been properly loaded, but the conn\_footprint.log is never created, the table/set we’re looking for may not be attached to a `connection`.

Do you still observe these kind of crashes from time to time and reproducible? At this point it might be easiest to look into setting up coredump handling (e.g. by installing systemd-coredump, or configuring /sys/kernel/core\_pattern and ulimit) for further investigation. Then look at the coredump with `gdb` and run `bt`for a backtrace. There’s also [zeek-gdb-utils.py](https://github.com/zeek/zeek-aux/blob/master/devel-tools/zeek-gdb-utils.py) that provides a `btz` command that resolves script function names on the stack.

```auto
1747314039.323292 fatal error: Dictionary (size 29273515) insertion distance too far: 65535
/scratch/split_and_zeek.sh: line 24: 3577145 Aborted (core dumped) zeek -r "${chunk}" /footprints.zeek # footprints.zeek has the include for the package

```

Thanks,

Arne

---

<div class="post-metadata">

**Author:** ![awelzel](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/awelzel/32/609_2.png) [@awelzel](https://community.zeek.org/u/awelzel)\
**Post date:** [August 21, 2026, 9:16am UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/13 "2026-08-21T09:16:37Z")

</div>

Hey @rachit - just wanted to check in if you’re still observing this or had anything more to share.

The 9.0 release got [a fix in the Dict code](https://github.com/zeek/zeek/pull/5731) that might address it.

If anyone else ends up in this thread and is able to reproduce “Dictionary (size 30158043) insertion distance too far: 65535”, please reach out, we’d like to fix this 👍

---

<div class="post-metadata">

**Author:** ![Benjamin\_Bannier](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/benjamin_bannier/32/595_2.png) [@Benjamin\_Bannier](https://community.zeek.org/u/Benjamin_Bannier)\
**Post date:** [August 24, 2026, 1:03pm UTC](https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-far-65535/7978/14 "2026-08-24T13:03:15Z")

</div>

> <https://github.com/zeek/zeek/issues/5824>
>
> In https://community.zeek.org/t/hitting-error-dictionary-insertion-distance-too-…far-65535/ a user reported running into a fatal error when processing a huge PCAP file while loading a script which uses expiry. This was hard to reproduce, so I asked an LLM (Claude Opus 4.6) to come up with a reproducer. Since hitting this seems to depend on bucketing (which depends on hashes), generating a good script-land reproducer was hard, but I was able to generate a C++ reproducer which IMO should still work. The crucial bit seems to be that holding a robust iterator prevents rebucketing which can trigger the bug.
> 
> This is the reproducer Opus generated which produces the fatal error in a couple of seconds in \`RelWithDebInfo\` for me. The comments all come from the LLM and might be completely bogus.
> 
> \`\`\`cxx
> TEST\_CASE("dict insertion distance too far under robust iteration") {
> // Reproducer for the "insertion distance too far: 65535" fatal.
> //
> // When a RobustDictIterator exists, Remap() is blocked. Inserting
> // entries whose hashes all collide into the same bucket creates a
> // single cluster that grows without redistribution. Once the
> // cluster exceeds 65535 entries, the scan distance in LookupIndex
> // hits the uint16\_t sentinel and triggers the fatal.
> Dictionary\<uint32\_t\> dict(UNORDERED);
> uint32\_t val = 0;
> 
> for ( uint32\_t i = 0; i \< 10; i++ ) {
> auto\* key = new detail::HashKey(static\_cast\<zeek\_uint\_t\>(i));
> dict.Insert(key, &val);
> }
> 
> auto iter = dict.begin\_robust();
> 
> // Hashes with lower 17 bits = 0 all map to bucket 0 regardless
> // of log2\_buckets (up to 17), since FibHash is multiplication by
> // an odd constant and bucket selection uses only the lower bits.
> constexpr detail::hash\_t step = 1u \<\< 17;
> constexpr int count = 66000;
> 
> for ( int i = 0; i \< count; i++ ) {
> uint32\_t key\_data = i + 1000;
> auto\* key\_copy = new char\[sizeof(key\_data)\];
> memcpy(key\_copy, &key\_data, sizeof(key\_data));
> detail::hash\_t h = static\_cast\<detail::hash\_t\>(i + 1) \* step;
> dict.Insert(key\_copy, sizeof(key\_data), h, &val, false);
> }
> 
> CHECK(dict.Length() \> 0);
> 
> while ( iter != dict.end\_robust() )
> ++iter;
> }
> 
> \`\`\`
> 
> \`\`\`console
> $ ./src/zeek --test -tc="dict insertion distance too far under robust iteration"
> \[doctest\] doctest version is "2.5.0"
> \[doctest\] run with "--help" for options
> fatal error: Dictionary (size 65543) insertion distance too far: 65535
> ===============================================================================
> /Users/bbannier/src/zeek/src/Dict.cc:437:
> TEST SUITE: Dict
> TEST CASE: dict insertion distance too far under robust iteration
> 
> /Users/bbannier/src/zeek/src/Dict.cc:437: FATAL ERROR: test case CRASHED: SIGABRT - Abort (abnormal termination) signal
> 
> ===============================================================================
> \[doctest\] test cases: 1 | 0 passed | 1 failed | 147 skipped
> \[doctest\] assertions: 0 | 0 passed | 0 failed |
> \[doctest\] Status: FAILURE!
> \[3\] 87934 abort ./src/zeek --test -tc="dict insertion distance too far under robust iteration
> \`\`\`