# How Generational-Box Provides Validity for Signals in Dioxus > Learn how generational-box ensures signal validity in Dioxus by pairing state with generation counters. Prevent use-after-free bugs with automatic invalidation. - Repository: [Dioxus Labs/dioxus](https://github.com/DioxusLabs/dioxus) - Tags: internals - Published: 2026-07-23 --- **Generational-box guarantees signal validity by pairing every state value with a generation counter tied to an Owner's lifetime; when the owner drops, the generation invalidates, causing any subsequent access to panic and prevent use-after-free bugs.** Dioxus implements its reactive primitives on top of the **generational-box** crate to provide validity for signals without runtime garbage collection. The system ensures that signals remain usable only while their creating scope exists, using a lightweight generational indexing approach that makes signal handles `Copy`-able yet memory-safe. ## The Owner-Generation Architecture At the heart of generational-box lies the **Owner**, which represents a runtime scope such as a component tree. When state is created, it captures an owner that manages an arena of generational boxes. According to the source code in [`packages/core/src/generational_box.rs`](https://github.com/DioxusLabs/dioxus/blob/main/packages/core/src/generational_box.rs), the storage system creates owners through `UnsyncStorage::owner()` or `SyncStorage::owner()`. These functions return a guard that automatically drops all associated boxes when it goes out of scope, recycling the underlying memory and incrementing the generation counter. ### Generation Counter Mechanics Each `GenerationalBox` stores its value in a `&'static RefCell>` alongside a generation number. The generation acts as a validity token that must match the owner's current generation for access to succeed. As documented in the crate's README at [`packages/generational-box/README.md`](https://github.com/DioxusLabs/dioxus/blob/main/packages/generational-box/README.md), the cells are recycled when the owner drops. This design allows the arena to reuse memory while making stale handles immediately detectable through generation mismatches. ## Validity Enforcement in Practice When a signal performs a read or write operation, the underlying `GenerationalBox` validates its generation first. The `read` and `write` methods compare the stored generation against the owner's active generation before dereferencing the internal `RefCell`. If the owner has been dropped—such as when a component unmounts—the generations differ and the operation panics. This prevents accessing freed memory or stale values, providing zero-cost safety for `Copy` signal handles without reference counting. ## Signal Integration in Dioxus Dioxus signals are thin wrappers around `GenerationalBox`. The architecture document at [`notes/architecture/04-SIGNALS.md`](https://github.com/DioxusLabs/dioxus/blob/main/notes/architecture/04-SIGNALS.md) explains that this design allows signals to be freely passed between components without cloning underlying data. Because `GenerationalBox` implements `Copy`, signal handles can be duplicated across component boundaries while still pointing to the same underlying storage. The validity guarantee ensures these copies never outlive their creating scope, even when moved across async boundaries or thread boundaries (with `SyncStorage`). ## Working with Generational-Box The following example demonstrates the explicit owner API that underlies Dioxus signals: ```rust use generational_box::{UnsyncStorage, Owner}; fn main() { // Create an owner representing a component tree's lifetime let owner: Owner = UnsyncStorage::owner(); // Insert a value into the owner's arena let handle = owner.insert(String::from("Hello")); // The GenerationalBox is Copy, allowing cheap duplication let cloned = handle; // Valid as long as owner lives assert_eq!(cloned.read().as_str(), "Hello"); // Owner drops here, invalidating all generations drop(owner); // This would panic: generation mismatch detected // let _ = cloned.read(); } ``` ## Summary - **Generational-box** ties every state value to an **Owner**'s lifetime via generation counters stored in [`packages/core/src/generational_box.rs`](https://github.com/DioxusLabs/dioxus/blob/main/packages/core/src/generational_box.rs). - Access methods validate generations before reading or writing to the underlying `RefCell`. - When an owner drops, its arena recycles and invalidates generations, causing subsequent access to panic rather than use freed memory. - Dioxus signals leverage `GenerationalBox`'s `Copy` semantics while maintaining memory safety through these runtime validity checks. ## Frequently Asked Questions ### What happens when you access a signal after its owner drops? The operation panics immediately. The `read` and `write` methods detect the generation mismatch between the `GenerationalBox` and the recycled owner slot, aborting execution to prevent use-after-free vulnerabilities. ### Why does GenerationalBox implement Copy instead of Clone? Because the underlying storage uses a `&'static` pointer to a `RefCell>`, the handle itself is just a pointer and generation number. This makes `Copy` zero-cost and allows signals to be passed freely between components without cloning or reference counting overhead. ### Where is the generation check implemented? The validation logic resides in [`packages/core/src/generational_box.rs`](https://github.com/DioxusLabs/dioxus/blob/main/packages/core/src/generational_box.rs). Every read and write operation on a `GenerationalBox` compares its stored generation against the current owner state before accessing the internal data. ### Can generational-box be used outside of Dioxus? Yes. While Dioxus uses it for signals, the crate is standalone. Any Rust code can create an `Owner` via `UnsyncStorage::owner()` or `SyncStorage::owner()` and store values in `GenerationalBox` handles to get the same lifetime-validated, `Copy`-able memory management.