src/plugins.d/pluginsd_internals.h:132

• Data race on st->pluginsd.dims_with_slots: This field is written non-atomically here but is read without holding the spinlock in multiple reader functions (e.g., pluginsd_end_v2 line 1100, pluginsd_acquire_dimension line 191). If the realloc path is taken, this could create a race where readers see an inconsistent state. Either protect writes to dims_with_slots with the spinlock and require readers to acquire it, or use atomic operations for this field as well.

        st->pluginsd.dims_with_slots = true;
        wanted_size = slot;

src/database/rrdset-slots.c:67

• The function rrdset_pluginsd_receive_unslot modifies array elements (lines 52-54) without holding the spinlock, yet it can be called from multiple contexts including collector threads. This creates a race condition where:

1. A collector thread could be in pluginsd_clear_scope_chart() or pluginsd_rrdset_cache_put_to_slot() calling this function
2. Meanwhile, the cleanup thread in rrdset_pluginsd_receive_unslot_and_cleanup() could have checked collector_tid, found it to be 0, and proceeded to free the array

Even though the cleanup code now uses atomic operations to NULL the array pointer, there's still a window where a collector thread could have loaded the array pointer before it was NULLed, then the cleanup thread frees it, and then the collector thread tries to modify the freed memory.

The atomics for loading prd_array and prd_size protect against use-after-free when reading, but not when modifying the array contents. This function should either:

1. Be called only while holding the spinlock, OR
2. The modifications to array elements should be made atomic/synchronized, OR
3. The collector_tid should remain set during the entire time this function is executing

void rrdset_pluginsd_receive_unslot(RRDSET *st) {
    // Use atomic loads with ACQUIRE semantics to synchronize with cleanup code
    // that uses RELEASE semantics when freeing the array
    struct pluginsd_rrddim *prd_array = __atomic_load_n(&st->pluginsd.prd_array, __ATOMIC_ACQUIRE);
    size_t prd_size = __atomic_load_n(&st->pluginsd.size, __ATOMIC_ACQUIRE);

    for(size_t i = 0; i < prd_size && prd_array; i++) {
        rrddim_acquired_release(prd_array[i].rda); // can be NULL
        prd_array[i].rda = NULL;
        prd_array[i].rd = NULL;
        prd_array[i].id = NULL;
    }

    RRDHOST *host = st->rrdhost;

    if(st->pluginsd.last_slot >= 0 &&
        (uint32_t)st->pluginsd.last_slot < host->stream.rcv.pluginsd_chart_slots.size &&
        host->stream.rcv.pluginsd_chart_slots.array[st->pluginsd.last_slot] == st) {
        host->stream.rcv.pluginsd_chart_slots.array[st->pluginsd.last_slot] = NULL;
    }

    st->pluginsd.last_slot = -1;
    st->pluginsd.dims_with_slots = false;
}

src/plugins.d/pluginsd_internals.h:140

• The non-atomic writes to st->pluginsd.dims_with_slots (lines 136, 140) create a data race with the cleanup code that reads this field (line 1100 in pluginsd_parser.c and elsewhere). Since dims_with_slots is accessed without synchronization by both the collector and cleanup threads, this is a data race under the C memory model.

While the field itself may not cause crashes since it's a boolean, it should be accessed atomically to avoid undefined behavior. The cleanup code sets it to false (line 103 in rrdset-slots.c) without atomics, while readers check it without atomics (line 1100 in pluginsd_parser.c, line 161 in this file, line 196 in this file).

Consider using atomic operations for this field or ensuring it's only modified/read while holding the spinlock.

        st->pluginsd.dims_with_slots = true;
        wanted_size = slot;
    }
    else {
        st->pluginsd.dims_with_slots = false;

src/plugins.d/pluginsd_internals.h:140

• After atomically loading prd_array and prd_size, the code still directly modifies st->pluginsd.dims_with_slots without atomic operations or lock protection. This creates inconsistency - a reader might load the old array but see the new dims_with_slots value (or vice versa), leading to undefined behavior.

The dims_with_slots flag should either be set atomically with appropriate memory ordering, or the entire pluginsd_rrddim_put_to_slot operation should be protected by st->pluginsd.spinlock.

    if(slot >= 1) {
        st->pluginsd.dims_with_slots = true;
        wanted_size = slot;
    }
    else {
        st->pluginsd.dims_with_slots = false;