Memory Safety, AddressSanitizer, and Logical Lifetimes in Tina

📚 Part 3 • The Architecture of Tina

+ 2 more articles in this series

✓ Why Queues Don’t Fix Overload (And What To Do Instead)
✓ Building an HTTP Server on a Thread-per-Core Framework, without Async/Await
→ Memory Safety, AddressSanitizer, and Logical Lifetimes in Tina

View full series → 🔔 Get notified of new articles

Tina is a concurrency framework built around the core principles of safety, fault tolerance, deterministic behavior, and simple yet performant. They aren’t features bolted onto the runtime, rather they shape almost every architectural decision in the framework.

Although Odin already provides a strong type system, that alone cannot guarantee the kinds of safety properties a long-running concurrent system needs. Tina instead treats safety as a layered stack, where each layer constrains what code can do, eliminating entire classes of bug before they can occur.

Here’s what that stack looks like:

┌─────────────────────────────────────────────────────────────┐
│  Level 5: Deterministic Simulation Testing                  │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Structural Checkers · Fault Injection · Seed Replay   │  │
│  └───────────────────────┬───────────────────────────────┘  │
├──────────────────────────┼──────────────────────────────────┤
│  Level 4: Process Lifecycle & Watchdog                      │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Heartbeat Monitor · Graceful Shutdown · Force Kill    │  │
│  └───────────────────────┬───────────────────────────────┘  │
├──────────────────────────┼──────────────────────────────────┤
│  Level 3: Three-Level Recovery Hierarchy                    │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐   │
│  │ L1: Isolate  │  │ L2: Shard    │  │ L3: Process      │   │
│  │ Restart      │→ │ Mass Teardown│→ │ Abort (OS kill)  │   │
│  │ (supervisor) │  │ + Rebuild    │  │ + External rest. │   │
│  └──────┬───────┘  └──────┬───────┘  └────────┬─────────┘   │
│         │ restart budget  │ quarantine        │ kernel      │
│         │ exceeded        │ policy            │ reclaim     │
├─────────┴─────────────────┴───────────────────┴─────────────┤
│  Level 2: Trap Boundary (Hardware Fault Isolation)          │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Nested sigsetjmp/siglongjmp (POSIX)                   │  │
│  │ Catches: SIGSEGV · SIGBUS · SIGFPE · SIGILL · panic   │  │
│  │ Outer trap ── Shard recovery                          │  │
│  │ Handler trap ── Isolate dispatch recovery             │  │
│  │ Init trap ── Isolate spawn failure recovery           │  │
│  │ Guard pages between each Shard's memory region        │  │
│  └───────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│  Level 1: Memory Safety & Resource Management               │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 3-Lifetime Arena Allocator                            │  │
│  │ Bounded Resources (pre-sized data structures)         │  │
│  │ Code Sanitizers (ASan, TSan, MSan)                    │  │
│  │ Lock-free data structures                             │  │
│  └───────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│  Level 0: Architecture Constraints                          │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Shared-Nothing · Thread-Per-Core · Cooperative Sched. │  │
│  │ Static Allocation + Boot-time Spec Validation         │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Each layer is independently useful, but together they reinforce each other. This is a broader view of safety than the one often discussed in programming language forums, where safety tends to mean the type system, a borrow checker” or a garbage collector. Those are valuable tools, but they’re only one layer of a much larger system.

This article focuses on Level 1 (memory safety), more specifically, how Tina integrates AddressSanitizer (ASan). The other layers provide important context because they explain why ASan alone isn’t enough, but we’ll move through them quickly before diving into the implementation.

How the Safety Layers Compose

Level 0 is a conceptual layer that removes various failure domains through architectural constraints. A shared-nothing architecture eliminates data races by construction. Static allocation during startup eliminates out-of-memory failures and heap fragmentation during normal execution. Every memory requirement is declared up front, validated during startup, and the process refuses to start if a constraint is violated.

Bounded resources reinforce those guarantees. Fixed-size queues and pre-allocated data structures cannot silently grow until the process collapses under load. Instead, the system sheds work in a controlled manner. I covered the reasoning behind that design in Why Queues Don’t Fix Overload.

Level 1 builds on those guarantees with a memory model based around three scheduler-known arena lifetimes: Shard permanent, per-Isolate, and per-handler scratch.

The Shard-permanent memory lives for as long as the Shard exists. Per-Isolate memory lives only for the lifetime of an Isolate. The scratch arena exists only for the duration of a single handler invocation before being automatically reset. Together, these lifetimes dramatically reduce the scope for accidental memory misuse while keeping allocation predictable and inexpensive.

Level 2 introduces trap boundaries that recover from hardware faults such as segmentation faults, divide-by-zero, illegal instructions, and panics. Tina uses three nested recovery points:

Isolate trap boundary: wraps each Isolate dispatch so failures affect only that Isolate. Recovery tears down the failed Isolate before execution continues.
Shard trap boundary: wraps the scheduler loop itself. Failures outside an Isolate trigger Shard teardown and reconstruction.
Isolate initialisation trap: wraps Isolate creation so that panics during initialisation safely roll back partially constructed state.

The supervision system, inspired by Erlang/OTP, sits at Level 3. Rather than treating every failure equally, it escalates through three recovery levels: restarting a single Isolate, rebuilding an entire Shard, and finally terminating the process so an external supervisor can restart it.

Level 4 manages the process lifecycle. A watchdog thread monitors Shards, detects failures that escape lower layers, and coordinates graceful shutdown. The scope at this layer is quite small, but I might expand its responsibilities as the framework matures.

Finally, Level 5 is Tina’s deterministic simulation environment. It injects I/O failures, delayed messages, forced crashes, and other fault conditions while verifying structural invariants after every recovery boundary. Every simulation can be replayed exactly from its random seed, so that intermittent failures are reproducible.

The architecture embraces the “let it crash” philosophy. Crashes are designed to be cheap, isolated, and recoverable. The simulator then repeatedly proves those recovery paths by deliberately breaking the system under controlled conditions.

Code Sanitizers

The architectural layers prevent many bugs before the compiler gets involved. But we can also use compiler sanitizers as an additional line of defence by detecting mistakes that still occur during development.

A compiler sanitizer is a specialised dynamic analysis tool that instruments your program with additional runtime checks. Unlike static analysis which reasons about code without executing it, sanitizers observe actual execution and report problems the moment they occur.

The LLVM toolchain provides several such sanitizers, each targeting a different category of bug:

AddressSanitizer (ASan) detects memory errors such as use-after-free, use-after-scope, use-after-return, double free, invalid free, and buffer overflows.
LeakSanitizer (LSan) is integrated into ASan and performs leak detection just before the process exits.
ThreadSanitizer (TSan) detects unsynchronised concurrent accesses to shared memory.
MemorySanitizer (MSan) detects reads from uninitialised memory. Although this tends to be less useful in Odin because variables are zero-initialised by default.

Each sanitizer solves a different problem, and Tina uses them alongside both its simulation and non-simulation test suites. They’re also integrated into the project’s GitHub Actions workflow so these checks run on every commit.

Of those tools, AddressSanitizer required by far the most integration work. Not because of a limitation in ASan, but because Tina deliberately breaks one of ASan’s core assumptions about memory management.

AddressSanitizer

AddressSanitizer (ASan) detects memory errors by tracking which parts of your program’s address space are currently valid to access. It does this by maintaining a parallel shadow memory, where every byte represents the state of eight bytes of application memory.¹

The compiler instruments every memory access with lightweight checks against this shadow memory. When memory becomes invalid, for example after free(), ASan poisons the corresponding shadow bytes. Any subsequent read or write immediately aborts the program with a detailed diagnostic showing where the invalid access occurred.

This model works for traditional allocators because logical lifetime and physical lifetime are effectively the same. Once memory is freed, it becomes invalid.

This assumption doesn’t work for Tina because of its memory model.

The framework allocates a Grand Arena — a large memory region from which the framework’s allocators are created — during startup. From that point onwards, no memory is returned to the operating system until the process exits. There are no allocator alloc() or free() calls for ASan to observe.

As far as ASan is concerned, the entire arena remains valid and addressable.

The problem is that Tina still has logical lifetimes. An Isolate slot, a message envelope, or a ring buffer entry may have been released and reused many times, even though the underlying memory has never changed. A stale pointer into one of those regions can silently access a completely different logical object because the memory is still mapped and physically addressable.

ASan cannot detect that on its own because, from its perspective, nothing was ever freed.

To bridge that gap, Tina explicitly interacts with ASan about its logical ownership model by poisoning and unpoisoning memory whenever ownership changes. Instead of relying solely on physical allocation events, ASan now observes the same logical lifetime transitions that the framework itself enforces.

Manual Poisoning of Every Logical Lifetime

Every logical lifetime in Tina follows the same contract:

Poison on logical release. Unpoison on logical allocation.

Whenever ownership of a memory region ends, Tina marks it as poisoned. Whenever that region is assigned to a new logical owner, Tina marks it as unpoisoned.

The poison/unpoison operations uses the functions Odin exposes through the base:sanitizer package to hook into the ASan runtime. Tina uses address_poison_rawptr and address_unpoison_rawptr from that package to update ASan’s shadow memory as ownership changes. These operations don’t allocate, free, or move memory, they simply tell ASan whether a region should be considered addressable or not. That makes them inexpensive enough to perform at every logical lifetime transition during testing.

All of the hooks used are gated behind the compile-time constant:

TINA_ASAN_POISONING :: .Address in ODIN_SANITIZER_FLAGS

Building with -sanitize:address enables ASan instrumentation. Without it, every when TINA_ASAN_POISONING { ... } block disappears at compile time, leaving production builds with zero runtime cost and no additional binary size. The six domains below all implement the poinson/unpoison contract, each applied to a different ownership model within the framework.

1. Isolate Slots (Message Payload + Working Memory)

An Isolate slot becomes logically free the moment an Isolate exits or crashes. At that point the scheduler returns the slot to the free list and immediately poisons it. When a new Isolate is spawned into the slot, Tina unpoisons the region before any initialisation code executes.²

Without this, a stale pointer to the previous occupant silently reads or writes the new occupant’s state because the underlying memory never changed. Hardware traps cannot detect this because the memory is still mapped and physically valid. By poisoning the slot on teardown, ASan instead reports any invalid access.

2. Per-Handler Scratch Space

The per-handler scratch arena is a bump allocator whose lifetime ends with every handler invocation. Once a handler returns, the scheduler resets the arena and poisons the entire region. Subsequent allocations unpoison only the byte ranges that’s requested.³

This catches pointers that accidentally escape a handler turn. Instead of quietly reading stale data left behind by the previous invocation, any access after the handler returns faults immediately, making the lifetime violation obvious.

3. Message Pool

Message envelopes are recycled from a fixed-size memory pool. After a message has been delivered, the scheduler returns its slot to the pool and poisons it. When that slot is reused for a new message, Tina unpoisons it again.⁴

A procedure that mistakenly retains a pointer after delivery would otherwise access an entirely different message later on. Because the pool operates within a single Shard, the ownership transition is straightforward: poison on explicit release, unpoison on explicit allocation.

4. I/O Buffer Slots

An I/O buffer alternates between two owners: Tina and the operating system.

Before submission, the handler owns the buffer and may freely access it. Once the request is submitted, ownership transfers to the kernel. Tina immediately poisons the entire slot and keeps it poisoned until the completion event returns ownership back to user space, at which point it unpoisons that region.⁵

This protects against an otherwise invisible class of bug. While an I/O request is in flight, the kernel may be reading from or writing to that memory, but the CPU has no concept of “kernel-owned” memory. Without poisoning, a stray write from application code silently races with the kernel, leading to unexpected behaviour. With poisoning enabled, ASan reports the first invalid access, thereby preventing such bugs. This invariant must be maintained, otherwise we run into issues that are very difficult to debug.

5. SPSC Ring Buffer Slots

The Single-Producer Single-Consumer (SPSC) ring buffer is the only domain where the ordering of the ASan hook itself becomes critical.

After the consumer finishes reading a slot, it advances a sequence number to publish that the slot is available again. Tina poisons the slot before performing that atomic store. The producer unpoisons the slot immediately before writing new data into it.⁶

If those two operations happened in the opposite order — publishing first, poisoning second — the producer could begin writing while ASan still considered the slot valid for the consumer. Poisoning before publication closes that race entirely.

Unlike the message pool, this isn’t an explicit free operation. Ownership changes through cross-thread coordination, so the poisoning point naturally follows the synchronisation primitive rather than a memory allocator.

6. Logging Subsystem

The logging subsystem maintains a circular buffer with independent read and write cursors. Everything between those cursors represents committed log entries that have not yet been flushed. Everything outside that region is deemed available for reuse.

Tina therefore keeps only the unflushed region unpoisoned. As the write cursor advances, newly committed entries become unpoisoned. As the read cursor flushes entries, those regions are immediately poisoned again.⁷

Without this, any code holding a pointer into flushed log memory region would quietly observe whichever log entry happened to occupy that location next. ASan instead reports the stale access the moment it occurs.

Across all six domains, the implementation follows the principle mentioned earlier: every logical ownership transition is mirrored in ASan’s shadow memory. By ASan learn about Tina’s logical lifetimes instead of only its physical allocations, the framework turns various category of silent stale-pointer bugs into immediate, actionable diagnostics.

Detecting Memory Leaks

AddressSanitizer can also detect memory leaks, although LLVM still describes that feature as experimental.⁸

For leak detection, however, Tina primarily relies on Odin’s tracking allocator. It reports memory leaks and invalid frees, and integrates directly with Odin’s testing package. Every test in Tina runs with the tracking allocator enabled, allowing leaks to be caught during test execution without requiring a dedicated LeakSanitizer pass.

Wrapping Up

Memory safety isn’t the result of a single tool or language feature. It’s the outcome of multiple layers working together, with each one reinforcing the guarantees provided by the others. In Tina, the architecture eliminates entire classes of bugs before the program even runs. Arena lifetimes constrain ownership. Trap boundaries contain software/hardware faults. Deterministic simulation repeatedly validates recovery paths. Compiler sanitizers then verify that the implementation faithfully respects those guarantees.

AddressSanitizer plays a particularly interesting role in that stack.

By default, ASan understands physical memory lifetimes: allocation, use, and free. Tina, on the other hand, keeps almost all of its memory allocated for the lifetime of the process. From ASan’s perspective, nothing ever becomes invalid.

The solution is to help ASan find the framework’s logical lifetimes instead.

Every time ownership changes — whether it’s an Isolate slot, a message envelope, an I/O buffer, a ring buffer entry, or a log buffer — Tina mirrors that transition into ASan’s shadow memory. The result is that ASan observes the same ownership rules the runtime itself enforces, exposing bugs that would otherwise remain completely invisible.

In that sense, Tina and ASan are a bit like Batman and Robin. Individually they’re effective, but together they cover each other’s blind spots. Tina supplies the logical ownership model; ASan does the runtime verification.

What’s Next

ThreadSanitizer (TSan) is already part of Tina’s GitHub Actions pipeline, but it isn’t exercising the most interesting code yet. The current unit and simulation tests are either single-threaded or replace various platform components under the TINA_SIM=true flag, leaving some critical cross-thread coordination paths outside TSan’s reach.

I’m currently exploring ways to improve that and hope to have a solution in place by the end of July or August.

Beyond that, I’d like to build a dedicated machine that continuously runs deterministic simulation tests (similar to TigerBeetle’s VOPR), as well as a microbenchmark suite covering Tina’s APIs and runtime boundaries. Watching performance and behavioural changes over time is just as valuable as catching correctness regressions.

If either of those sounds interesting, I’d love to hear from you.

Building this kind of infrastructure takes a significant amount of time and experimentation. If you’d like to support that work, you can do so financially via GitHub Sponsors, contribute code or examples, or simply give the project a star on GitHub. Every contribution helps move the project and Odin ecosystem forward.

Finally, give Tina a try and let me know what you think. There are several examples—including an HTTP server—to help you get started.

Notes & References