Fixes this compiler warning:
src/digest.cc: In function ‘EVP_MD_CTX* hash_init(HashAlgorithm)’:
src/digest.cc:44:26: warning: ‘md’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if ( ! EVP_DigestInit_ex(c, md, NULL) )
~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
Minor whitespace fixes during merge.
* 'smart_ptr' of https://github.com/MaxKellermann/zeek:
OpaqueVal: remove misplaced `virtual` keywords
CompHash: use class IntrusivePtr for the `type` field
IntrusivePtr: replace the "add_ref" parameter with tag structs
IntrusivePtr: remove reset(), nobody uses it
IntrusivePtr: remove ordering operators
IntrusivePtr: rename detach() to release()
IntrusivePtr: move nullptr initializer to field declaration
Updated the Ref() to happen inline with Assign() call for clarity.
* 'expr_missing_ref' of https://github.com/MaxKellermann/zeek:
Expr: add missing reference in AssignExpr::InitVal()
This method mimicks std::unique_ptr::reset(), but adds an obscure
"add_ref" parameter which is error prone. Since nobody uses this
method, and this method is all about dealing with raw pointers which
we shouldn't be doing, let's remove it.
The one reference returned by `op2->InitVal()` is given to
`aggr_r->Assign()` and returned to the caller, which may result in a
use-after-free crash bug. This patch adds the missing reference.
Closes https://github.com/zeek/zeek/issues/805
The merge commit fixes reference counting issues introduced with the
changes to ListExpr::Assign() and IndexExpr::Assign(), but then also
several other pre-existing reference counting confusions in other
Assign() implementations/calls, some which were now directly observable
via new crashing behavior, others just from a cursory code audit.
* 'memleaks' of https://github.com/MaxKellermann/zeek:
input/Manager: fix memory leak in UnrollRecordType()
OpaqueVal: fix two memory leaks in BloomFilterVal::Merge()
DbgBreakpoint: fix memory leak
DebugCmds: fix memory leak
scan.l: fix crash bug in do_atif()
Expr: fix memory leak in RecordConstructorExpr::InitVal()
Expr: fix memory leaks in AssignExpr::EvalIntoAggregate()
Expr: fix memory leaks in CondExpr::Eval()
Expr: fix several memory leaks in BoolExpr::Eval()
Expr: fix various memory leaks in Assign()
Expr: fix memory leaks in BinaryExpr::Eval()
analyzer/protocol/http: fix potential memory leak
The `Val*` return by Expr::Eval() is never freed. Note that it must
be freed after the `Field` object has been created, because the
`secondary` variable points to data inside the `Val*`.
This is really a memory leak because the Unref() call is missing. But
since this usually returns a "stock" object (`ValManager::b_true` or
`ValManager::b_false`), nothing really leaks. But eventually, the
reference counter will overflow to `INT_MAX`, leading to a crash in
bad_ref().
No code path had any cleanup code, leaking all the local references.
More weird was however the result building code: it took elements from
one of the existing vectors without referencing them, and passed them
to VectorVal::Assign() which assumes that the caller-owned reference
is now owned by that VectorVal.
Even in the successful code path, no references were freed.
Everything was wrong with this method!
Copying a BroObj is dangerous, and should only be done with dedicated
(virtual) methods which are implemented by all derived classes. This
commit avoids unintentional copies.
If it were legal to call SendReplyOrRejectEvent() without an
EventHandlerPtr, then this would leak the `question_name` object. But
this method has just one caller, and it verifies the EventHandlerPtr.
If `dns_TSIG_addl` is not set, then the BroString allocated by
ExtractOctets() leaks. Therefore, don't ask ExtractOctets() to copy
the data to a BroString if we're not going to use it.
Yet another memory leak (out of way too many) which would have been
prevented by using smart pointers.
