ARAL mmap page creation builds MAP_SHARED backing filenames from ar->aral_lock.file_number. Page creation happens before the page-list lock is reacquired, and lockless ARALs skip those locks entirely. The previous non-atomic increment plus later read could race between concurrent mmap page creators; two distinct ARAL pages could choose the same filename and alias the same backing storage.

Use a relaxed atomic add-fetch and format the filename from the returned value. The counter only needs uniqueness, not memory ordering, so the relaxed operation is sufficient and matches the existing counter style in this file.

Current vs potential bug: the race exists in the ARAL allocator contract today, but current registry mmap users appear externally serialized and mmap is disabled by default, so it is latent for the default production configuration. The fix hardens the allocator before a future mmap-backed concurrent caller can corrupt memory.

Functional impact: no intended behavior change. Filename format and monotonic numbering are preserved; the only changed behavior is that concurrent page creation can no longer reuse a filename.

Performance impact: one relaxed atomic increment is added only to the mmap page-creation path. This is cold compared with normal ARAL allocation and negligible beside allocation, filename creation, and mmap work.

(cherry picked from commit db380da)

MEM-parsers-002 is a current-path duration formatter bug with potential extreme-input faults: duration_snprintf() negated signed int64_t values directly, which is undefined for INT64_MIN, and multiplied signed values by unit nanosecond multipliers, which can overflow int64_t for large values and larger units.

Current vs potential: duration_snprintf() is used by current runtime paths for streaming, ACLK, retention, config, buffers, SQLite metadata, and collectors. The faulty path is current, but the dangerous inputs are extreme int64_t values rather than normal duration values.

Functional impact: normal duration formatting is unchanged for well-defined inputs. Extreme values that previously invoked undefined or wrapped signed arithmetic now format correctly on targets with unsigned __int128, or return the existing -3 error on fallback targets when the value cannot fit in uint64 nanoseconds.

Performance impact: negligible for current callers because this formats human-readable durations, not per-sample hot-path data. The fix adds bounded integer arithmetic and branch checks only.

Solution: compute negative magnitudes without negating INT64_MIN, use unsigned formatter arithmetic, guard fallback multiplication without __int128, round with quotient/remainder arithmetic, and add boundary tests for the formatter.
(cherry picked from commit c3a29f6)

The deadly-signal log path and its signal-code helper were re-scanning stack buffers with strlen() after already constructing bounded, null-terminated strings. This is a current low-severity crash-path defect because these paths run from the signal handler, where strlen() is not async-signal-safe.

Use the maintained byte length for the stderr write, and use strcatz() in SIGNAL_CODE_2str_h() so the helper gets the copied length directly while preserving the same bounded copy and terminator behavior.

Functional impact: none; the emitted crash message, formatted signal-code string, signal chaining, Sentry reporting, status-file handling, reset-to-default, and re-raise behavior are unchanged.

Performance impact: negligible improvement on rare crash/report paths by removing redundant stack-buffer scans.

(cherry picked from commit 4fa81f8)

The ARAL mmap page deletion path logged unlink failures as a bare filename, while the sibling leftover-file cleanup path includes both the ARAL prefix and the allocator name. The code already has the ARAL object in scope at the failure site, so operators could lose the allocator context needed to identify which ARAL instance failed to delete its backing file.

This is a current diagnostics defect on the existing unlink failure path, not a memory-lifetime or control-flow defect. The solution keeps the unlink call, branch condition, mmap/free order, locking, and caller behavior unchanged, and only formats the existing unlikely error log with ar->config.name to match the local ARAL diagnostic pattern.

Functional impact: no success-path or failure-control-flow change; only the text of the existing unlink-failure log becomes more specific.

Performance impact: effectively zero; one already-live string argument is formatted only when unlink() fails.

(cherry picked from commit aaadd71)

STREAM_CIRCULAR_BUFFER_STATS stored four byte-size snapshots as uint32_t even though the circular-buffer implementation uses size_t for the corresponding sizes. Buffers above UINT32_MAX would truncate these snapshots and corrupt buffer_ratio and diagnostic log values.

This is a current latent implementation defect with potential runtime manifestation. It requires a configured or autoscaled stream buffer above 4 GiB, but the truncation is deterministic once that size is reached.

Widen the stats snapshot fields to size_t and update the coupled log format specifiers to %zu. In the sender overflow path, copy the stats while still holding the sender lock before logging after unlock, preserving the existing safe snapshot pattern.

Functional impact: none intended except preserving the full size range in internal stats and logs. No streaming protocol, metric schema, disk format, API, config parser, or documentation surface changes in this commit.

Performance impact: negligible. On 64-bit builds the stats struct grows by 16 bytes per stream circular buffer; the change adds no allocations, loops, atomics, syscalls, or runtime complexity.

(cherry picked from commit e2d4b56)

The stream receiver byte counters bytes_in and bytes_out are 64-bit single-writer counters read lock-free by the pulse traversal. On 32-bit layouts, source review and reduced layout checks showed these fields could be placed at offsets not divisible by 8 while GCC can inline relaxed 64-bit access when it proves the target lock-free.

This is a current source-level alignment bug with potential runtime manifestation on affected 32-bit builds. The writer and reader call paths exist today through stream-receiver.c and pulse-parents.c.

Force the two current 64-bit single-writer counter fields to 8-byte alignment and update the helper contract comment so future 64-bit users carry the same requirement. The single-writer macro bodies, increments, reads, locks, lifetimes, chart names, dimensions, and algorithms are unchanged.

Functional impact: none intended except making the existing relaxed atomic counter contract valid on affected layouts. The affected fields are internal in-memory host status, not serialized or public ABI state.

Performance impact: no hot-path code generation change from this diff. On 64-bit platforms this alignment should be a no-op; on affected 32-bit layouts the internal status struct may gain padding.

(cherry picked from commit 757d386)

rfc3339_datetime_ut() checked only payload capacity before each append. When a caller supplied an exact-fit buffer for the visible payload, for example 20 bytes for 'YYYY-MM-DDTHH:MM:SSZ', the formatter could write the final payload byte and then the finish block would overwrite that byte with NUL while returning the pre-clobber length.

Current vs potential: this is current for direct callers of the public formatter API with undersized exact-fit buffers. Current in-tree production callers use RFC3339_MAX_LENGTH or larger, so they do not exercise the bad exact-fit case today.

Solution: change each append guard to require room for the payload plus a trailing terminator, then terminate at buffer[pos] unconditionally. This preserves full-size output and makes undersized exact-fit output report the visible prefix length that actually remains in the buffer.

Functional impact: none for current production callers with adequate buffers. The intended behavior change is limited to undersized buffers, which now get a coherent NUL-terminated prefix instead of a clobbered final byte and mismatched length.

Performance impact: none expected. The change is only constant-time capacity predicates and a simpler finish block.

(cherry picked from commit 20d40e9)

Several RRD functions paths built stack buffers from runtime string lengths: function registration and deletion sanitized the function name into char arrays sized by strlen(name), host_functions_to_dict() built versioned dictionary keys from strlen(t_dfe.name), and rrd_function_run() sanitized the caller source into a runtime-sized stack buffer. These are potential stack-exhaustion defects when function/source strings are large, even though ordinary plugin inputs are much smaller.

Replace the runtime-sized stack buffers with exact-size temporary heap buffers using the existing CLEAN_CHAR_P cleanup convention. In rrd_function_run(), transfer the sanitized source buffer directly into the inflight request and null the cleanup pointer, avoiding an extra strdupz() on the success path. Dictionary keys, sanitized bytes, stream function-delete names, callback behavior, and JSON/API output remain unchanged.

Current vs potential bug: potential in normal deployments, source-confirmed for these code paths because the allocation size is derived from runtime strings. Functional impact: no intended behavior change except avoiding unbounded stack allocation. Performance impact: negligible on non-hot registration/export/run paths; add/delete/export use one temporary heap allocation, while rrd_function_run() keeps the success-path allocation count effectively unchanged by removing the separate source strdup.

(cherry picked from commit 5d3e096)