DioxusLabs / DioxusLabs/dioxus
asset!() fails with "index out of bounds: the length is 256 but the index is 256" when the project path is deep enough
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
Building a project from a deep directory fails once an asset's absolute source path goes over 256 bytes. As best I can tell, manganis stores the absolute source path in a fixed 256-byte `ConstStr` (`MAX_STR_SIZE` in `const-serialize/src/str.rs`), and `ConstStr::new` writes into that buffer without a length check, so a longer path surfaces as an index-out-of-bounds during const eval instead of a "path too long" diagnostic.
Minimal repro, dx 0.7.10 with rustc 1.95.0 on Linux:
`Cargo.toml`
```toml
[package]
name = "dxrepro"
version = "0.1.0"
edition = "2021"
[dependencies]
dioxus = { version = "0.7.10", features = ["web"] }
```
`src/main.rs`
```rust
use dioxus::prelude::*;
const LOGO: Asset = asset!("/assets/logo.svg");
fn main() {
dioxus::launch(app);
}
fn app() -> Element {
rsx! {
img { src: LOGO }
}
}
```
plus any small file at `assets/logo.svg`.
From a short path this builds fine. Copy the same project to a directory deep enough that the absolute path of `assets/logo.svg` exceeds 256 bytes (mine was 290) and `dx build --platform web` fails with:
```
error[E0080]: index out of bounds: the length is 256 but the index is 256
--> src/main.rs:3:21
|
3 | const LOGO: Asset = asset!("/assets/logo.svg");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `LOGO::__ASSET` failed inside this call
|
note: inside `dioxus::prelude::macro_helpers::create_bundled_asset`
--> manganis-0.7.10/src/macro_helpers.rs:45:5
note: inside `BundledAsset::new`
--> manganis-core-0.7.10/src/asset.rs:78:35
|
78 | absolute_source_path: ConstStr::new(absolute_source_path),
note: inside `dioxus::prelude::macro_helpers::ConstStr::new`
--> const-serialize-0.8.0-alpha.0/src/str.rs:101:13
|
101 | bytes[i] = MaybeUninit::new(str_bytes[i]);
| ^^^^^^^^ the failure occurred here
```
On a larger real project we also saw what looks like the same limit hit from inside dx itself at bundle time, after the crate had compiled fine:
```
ERROR Thread tokio-rt-worker panicked at packages/const-serialize/src/str.rs:101:13:
index out of bounds: the len is 256 but the index is 256
ERROR dx build: Build panicked! JoinError::Panic(Id(42), "index out of bounds: the len is 256 but the index is 256", ...)
```
There the source paths were under 256 bytes, so I assume dx constructs some longer path string of its own during asset processing, but I have not pinned down which one.
Expected: either no fixed cap on the path length, or a diagnostic that says the asset path is too long and by how much. The workaround of building from a shorter directory works but is unpleasant to discover from an index-out-of-bounds. It also seems likely to come up more often now that coding agents and CI tooling routinely build from git worktrees with long autogenerated directory names, which is how we ran into it.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with const-serialize/src/str.rs, especially MAX_STR_SIZE and ConstStr::new, then trace the asset path through manganis/src/macro_helpers.rs and manganis-core/src/asset.rs. Reproduce with the deep-path example using dx build --platform web; done means an overlong path no longer causes an index-out-of-bounds panic and instead has no fixed cap or reports the path length clearly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100