Abstract

Hazard Pointers, a classic mechanism for safe memory reclamation in modern concurrent structures, struggle under overhead. A recent paper proposes a new validation strategy based on immutability, enabling simple and sound reuse of HP. This raises the question of how such bugs could be reproduced through fuzzing, and what would be required to make it effective.

본문

A recent PLDI paper addresses memory safety in concurrent systems.¹ While our lab emphasizes static analysis and dynamic bug detection to ensure code safety, this work takes a different approach:
it designs a runtime-compatible mechanism that enforces memory safety under concurrency.

Hazard Pointers (HP) are a foundational runtime mechanism for ensuring memory
safety in modern concurrent systems. They let threads declare which memory
nodes they access, preventing premature reclamation (freeing memory still in use).
This requires confirming a node’s reachability during traversal.
However, skipping logically deleted nodes for performance breaks this assumption,
and restoring correctness via frequent restarts is costly.

The paper proposes an alternative: treat deleted nodes as immutable,
so their outgoing pointers remain fixed and no new node can be inserted
in a way that renders them unreachable.

The verification of the method was conducted using concurrent separation logic, which is well-suited for reasoning about memory safety that threads protect disjoint portions of memory during access.

The paper’s refinement of a foundational mechanism is undoubtedly valuable, but it also raises a practical question: without such mechanism, how often do such theoretically unsafe behaviors actually lead to runtime violations?

Fuzzing could serve as a complementary method in answering this. In particular, selective instrumentation can guide fuzzing toward concurrency-critical code regions, allowing more targeted coverage measurement. To be effective in this context, fuzzing would require more precise triaging mechanisms that go beyond crash-based detection and incorporate deeper semantic validation. For example, this would require enhancing sanitizers to detect silent runtime violations that do not result in crashes.