n0-computer / n0-computer/iroh-docs
Leaking doc handles
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 74
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Description
Problem:
Iroh docs stop responding/returning value on some devices (low end Android phones).
I can reliably reproduce by having such code repeated a lot of times:
let status = docs
.open(doc_id)
.await
.unwrap()
.unwrap()
.status()
.await
.unwrap();
after n attempts this stops returning values and hangs suspended.
I see suspiciously growing handles count on a Document Status. Should this be continuously increasing counter?
Full suspicious code block
Here's some explanatory text before the code.
#[tokio::test]
async fn test_app() {
let secret_key = { SecretKey::generate(&mut rand::rng()) };
let endpoint = Endpoint::empty_builder(RelayMode::Disabled)
.secret_key(secret_key)
.bind()
.await
.unwrap();
let mdns = MdnsDiscovery::builder().build(endpoint.id()).unwrap();
endpoint.discovery().add(mdns.clone());
let pinger = iroh_ping::Ping::new();
let blobs_store = MemStore::new();
let gossip = Gossip::builder().spawn(endpoint.clone());
let docs = Docs::memory()
.spawn(endpoint.clone(), (*blobs_store).clone(), gossip.clone())
.await
.unwrap();
let _router = Router::builder(endpoint.clone())
.accept(iroh_ping::ALPN, pinger.clone())
.accept(iroh_blobs::ALPN, BlobsProtocol::new(&blobs_store, None))
.accept(iroh_gossip::ALPN, gossip.clone())
.accept(iroh_docs::ALPN, docs.clone())
.spawn();
let doc_id = docs.create().await.unwrap().id();
for _ in 0..100 {
let doc = docs.open(doc_id).await.unwrap().unwrap(); // Does this leak the memory even if the resource is dropped?
// doc.close().await.unwrap();
}
let status = docs
.open(doc_id)
.await
.unwrap()
.unwrap()
.status()
.await
.unwrap();
assert_eq!(1, status.handles);
}
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reproduction using Docs::memory(), repeated docs.open(doc_id) calls, and the final status() check; trace how opened document handles are released when the returned value is dropped. Run the async test on a constrained-device-like setup, and consider the issue done when repeated opens do not hang and status.handles remains 1 after the handles are dropped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100