fix use-after-free of a blackboard entry held by getAnyLocked (alternative to #1181)

[facontidavide]

Alternative to #1181, same bug, smaller and ABI-transparent fix. The AnyPtrLocked* regression tests are taken from #1181 (thanks @aysha-afrah26, credited as co-author).

Bug

Blackboard::getAnyLocked() returns an AnyPtrLocked: a raw Any* plus the raw, locked entry_mutex of a Blackboard::Entry. Nothing keeps the Entry alive, so unset(), clear(), cloneInto() or ~Blackboard can destroy it while the handle is in use: heap-use-after-free (seen on the Groot2 thread, ExportBlackboardToJSON vs an UnsetBlackboard node).

LockedPtr can not become an owning handle: it is returned by value from exported functions and its ctor/dtor are inlined in user binaries, so its layout (two raw pointers) is ABI.

Fix

Attach a custom deleter to every Entry at its only two allocation sites (both in src/blackboard.cpp). When the last shared_ptr is dropped:

• mutex free and nothing parked (the normal case): delete immediately, no lock, no allocation;
• mutex still locked by a holder: the entry is parked and destroyed by a later sweep (next entry retirement or creation) that finds it unlocked.

Compared with #1181:

• Every removal path is covered with no change to it, including the unset() and ~Blackboard already inlined into binaries built against the 4.10 headers: they get the fix by just upgrading the library. A future removal path can not forget the protocol.
• getAnyLocked() is untouched (no second lookup / retry loop on the read path).
• Source change is +66 lines in blackboard.cpp; no layout or symbol change.

Also in this PR (from review): unset(), clear() and cloneInto() now destroy the removed values after releasing storage_mutex_; doc note in LockedPtr that the pointer is not valid after unlock().

Known limits (shared with #1181, inherent to the 16-byte handle)

• The sweep may call try_lock() on a mutex owned by the calling thread (holder and remover on the same thread). Formally undefined for std::mutex, but it simply fails on the supported platforms; documented in the code. TSan does not object.
• unlock() -> removal -> lock() on the same handle is still unsafe. A real fix needs an owning handle, i.e. an ABI break (BT.CPP 5).
• A parked value's destructor is delayed until the next entry creation/retirement.

Verification

• 7 tests (6 from fix use-after-free of a blackboard entry held by getAnyLocked #1181 + a 2-readers-vs-set/unset stress test): all fail on master (6 with ASan heap-use-after-free) and pass here.
• ASan+UBSan 60/60, TSan 40/40 on the Blackboard / thread-safety / Groot2 / JSON suites; full Debug suite 528/528.
• The design was compared against fix use-after-free of a blackboard entry held by getAnyLocked #1181 by two independent reviewers (given both diffs blind, as "A" and "B"); both chose this approach, and their required changes are included.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE