It looks like there is no reason to keep sessions in the map beyond the
point where the session manager is considered done. This hopefully
simplifies the shutdown control flow a tiny bit.
This test is very sensitive to new enum values that perturb the final
order of the output. Listing the commits that modify that file in the
past clearly shows changes to the baseline happen when a new component
with an enum value is introduced.
40f04d4ccf broker: Add WebSocketShim backend
51836d08ae protocol: Add StreamEvent analyzer
fdde1e9841 cluster/serializer: Add binary-serialization-format
6fb73aa9da broker: Add shim plugin adding a backend component
85ca59484b postgresql: Initial parser implementation
efc2681152 WebSocket: Introduce new analyzer and log
...
That's just distraction. Point fix the test to sort the analyzers before
writing the final log line.
I've previously attempted this in a more complete fashion in PR #3365
(issue #3364), but seems this direct fix might just make more sense.
This test has become flaky after #4295. It hasn't been failing regularly
enough locally to make it approachable. Annotate with
BTEST_BG_RUN_SLEEP=1 to revert to pre #4295 behavior, hopefully
fixing the flakiness as a side-effect.
After further testing with the fuzzer corpus, std::unreachable isn't
necessary here. It's fine to just let the default case break to fix
the Coverity warning.
* topic/timw/coverity-fixes:
Add move assignment operator to ZeekString, which already had a move constructor
Don't initialize telemetry listener at all if ZEEKCTL_CHECK_CONFIG is set
Avoid extra temporary strings in concatenation
Use const auto references to avoid some copies
Clean up initialization of TunnelEncapsulation to use default member values
Remove some unnecessary std::move calls in broker::Manager
Avoid divide-by-zero in CardinalityCounter::Size
Minor fixes in POP3 analyzer based on flycheck warnings
More std::move changes based on Coverity findings
Fix a potential memory leak in Debug function
* origin/topic/timw/4281-unconditionally-forward-out-of-snap:
Make SNAP analyzer use both OUI and protocol for forwarding
Change packet analyzer identifiers to be 64-bit
* origin/topic/awelzel/set-val-on-ids-for-enums:
broker/main: Adapt enum values to agree with comm.bif
btest/plugin: Add plugin testing enum identifiers
Var/add_type: Do not clone EnumType when declared for the first time
type/id/zeekygen: Add EnumVal to enum identifiers
Logic to detect this error already existed, but due to enum identifiers
not having a value set, it never triggered before.
Should probably backport this one.
EnumType receives the name into its constructor. Even for the first declaration
the name is not empty and instead the same as the identifier's name. Due to that,
add_type() previously took the else path and created a shallow clone of the
initial type instead of using it. This lead to buggy behavior where enum value
identifiers declared within an enum's first body have a different TypePtr
associated than the one that is found via `zeek:🆔:find_type()`. It also
means that enum identifiers added via redef later would have a different
TypePtr than those in the initial pointer.
Since commit 0a813a53c7,
zeek::detail::stmts is set to a nullptr when before it was usually
an empty list of statements. This caused traverse_all() to be
short-circuited unless global statements were available.
Fixes#4323
The logic was template-based so far, which wasn't great because: (1)
conceptually, it models the Spicy types at the wrong layer (C++ rather
than HILTI types), and (2) stopped working with some recent Spicy
updates (which we have temporarily reverted in the meantime to keep
Zeek working).
The new code is based on HILTI's runtime type information and the
corresponding introspection API, pretty much like `spicy-dump` works
as well. This is the recommended approach for working with HILTI
values, and generally much cleaner.
This is on top of https://github.com/zeek/zeek/pull/4300.
