Potential issue: NETDATA_TRACE_ALLOCATIONS used a fixed 0x0BADCAFE header magic to decide whether freez, reallocz, and mallocz_usable_size owned a pointer. A foreign libc pointer with that word at the expected offset could be misclassified and sent through the trace-accounting path.

Functional impact: normal builds do not enable this trace allocator path. Traced builds keep the same fallback behavior for foreign pointers and valid Netdata trace allocations.

Performance impact: ownership validation remains O(1) and keeps the same header size. The check adds only a pointer xor/fold against a static salt.

Store an address-derived magic in traced allocation headers and verify the computed value before using trace metadata or freeing the computed header.

(cherry picked from commit aaab1fe)

Potential: trace allocation builds resolve libc allocator pointers with dlsym(RTLD_NEXT) during first use. If dlsym re-enters an interposed allocation wrapper before the real pointer is installed, the resolver can recurse instead of reaching libc.

Functional impact: default and non-trace builds are unchanged because the change is inside NETDATA_TRACE_ALLOCATIONS plus dlsym guards. Trace+dlsym builds now service allocator calls made during dlsym from a fixed bootstrap buffer and avoid passing retained bootstrap pointers into traced or libc realloc paths.

Performance impact: default builds have no runtime cost. Trace+dlsym builds add only unlikely wrapper checks and a one-time thread-local depth guard around first-run dlsym resolution.

(cherry picked from commit f0b465c)

NETDATA_TRACE_RWLOCKS debug wrappers still modeled destroy, lock, and unlock helpers as returning int, even though the underlying __netdata_* helpers and libuv operations are void. That stale contract also left the trace path using the removed netdata_thread_tag() name and old linked-list macro names.

This is a current opt-in build bug: compiling with NETDATA_TRACE_RWLOCKS reaches these wrappers today and fails on void return-value use and stale APIs. It is potential runtime risk only for trace builds because the affected code is behind the trace/debug configuration.

Align the trace debug wrapper signatures with the existing base helper contracts: destroy, lock, and unlock wrappers are void; init and trylock wrappers keep their int return values. Replace the stale thread-tag and linked-list helper names with current project APIs.

Remove the directly coupled avl_destroy_lock() status check for netdata_rwlock_destroy(). The rwlock destroy operation cannot report failure in either trace or non-trace mode, so the check was an impossible contract and would remain a compile error once the trace wrapper is corrected.

Functional impact: default builds are unchanged. Trace/debug builds preserve the same lock operations, timing samples, locker bookkeeping, fatal unlock checks, and trylock failure behavior; they only stop exposing fabricated status values for operations that cannot return status.

Performance impact: none for default builds. Trace/debug builds keep the same instrumentation work, minus storing and formatting fabricated zero return values for void operations.

(cherry picked from commit f48449b)

Current issue: the existing ENABLE_FUZZER entry point exercised writer-produced gorilla buffers and reader roundtrips, but it did not feed arbitrary serialized disk-shaped buffers through gorilla_buffer_patch() and the disk-reader initialization path. This is a current coverage gap, not a production behavior bug.

Root cause: disk page repair and reader setup are normally reached from the dbengine disk-page load path, while the fuzzer only generated values through gorilla_writer_write(). Arbitrary corrupt disk bytes therefore did not exercise gorilla_buffer_patch(), gorilla_reader_init(), or malformed-reader termination.

Solution: add a fuzzer-only helper that copies the libFuzzer input into zero-padded gorilla-sized buffers, calls gorilla_buffer_patch(), and, on successful patching, initializes a gorilla reader and performs a bounded number of reads. The existing writer/reader roundtrip path remains unchanged and still runs for inputs with at least one uint32_t.

Functional impact: none for production builds because the change is entirely inside ENABLE_FUZZER. The libFuzzer entry point still returns 0 and still tolerates arbitrary input; malformed disk buffers are accepted as normal fuzzer inputs by returning from patch failure or breaking on reader failure.

Performance impact: none for production. Fuzzer-only work adds one input-sized allocation/copy rounded to gorilla buffer size and at most 16384 reader attempts after a successful patch, preventing attacker-controlled entry counts from creating long fuzz cases.

Caller and ownership impact: LLVMFuzzerTestOneInput is the only caller of the new helper. The helper mutates only a private copy of the input, owns its local Storage allocations, frees them before returning, adds no shared state, locks, or concurrency, and does not change dbengine page-loading callers.

(cherry picked from commit 6c1686f)