Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tracing-subscriber: Parent span ref_count + memory gets leaked when using a non-standard Registry type #2668

Open
Protryon opened this issue Jul 25, 2023 · 0 comments

Comments

@Protryon
Copy link

Protryon commented Jul 25, 2023

Bug Report

Version

tracing-subscriber 0.3.17

Description

Here:

These lines here silently require that the inner type is a Registry in order to run CloseGuard logic in sharded.rs.

#[cfg(all(feature = "registry", feature = "std"))]
let subscriber = &self.inner as &dyn Subscriber;
#[cfg(all(feature = "registry", feature = "std"))]
let mut guard = subscriber
    .downcast_ref::<Registry>()
    .map(|registry| registry.start_close(id.clone()));

CloseGuard::drop from here is the only way to call DataInner::clear here.

This results in the DataInner not being freed (memory leak I believe), and the parent span not having it's ref_count decremented, leading to the parent span being stuck in limbo for eternity.

I ran into this when wrapping the registry type to have it behind an Arc to do some OTEL shenanigans with more than 32 tracing fields.

jtescher pushed a commit to tokio-rs/tracing-opentelemetry that referenced this issue Jul 29, 2023
* Adds a function `set_attribute` to `OpenTelemetrySpanExt` to allow
setting attributes directly on the OpenTelemetry `SpanBuilder`.

This allows users to set more than the tracing maximum of 32 fields.

There was a workaround I came up with without using the function
involving wrapping the `Registry` in an Arc and accessing `OtelData`
directly, but that led to [this bug in
tracing-subscriber](tokio-rs/tracing#2668).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant