ETW Exporter: Crash When Ending ETW Exporter Span

[lukeina2z]

The same code works correctly when using the OpenTelemetry Tracer, Span, and OTLP Exporter. However, the application crashes when switching to the ETW Exporter.

Code to Reproduce (ETW Exporter)

  void TestEtwTracer()
  {
    auto traceProvider = std::make_unique<opentelemetry::exporter::etw::TracerProvider>();
    auto tracer = traceProvider->GetTracer("Geneva-Tracer-Foo");
    auto spanFoo = tracer->StartSpan("Span-Foo");
    tracer = traceProvider->GetTracer("Geneva-Tracer-Bar");
    auto spanBar = tracer->StartSpan("Span-Bar");
    spanFoo->End();
    spanBar->End();
  }

Crash Screenshot

Code to Reproduce (OTLP Exporter – Works as Expected)

  void TestOTelTracer()
  {
    auto ostream_exporter = opentelemetry::exporter::trace::OStreamSpanExporterFactory::Create();
    auto ostream_processor = opentelemetry::sdk::trace::SimpleSpanProcessorFactory::Create(std::move(ostream_exporter));

    std::vector<std::unique_ptr<opentelemetry::sdk::trace::SpanProcessor>> processors;
    processors.push_back(std::move(ostream_processor));

    auto resource_attributes = opentelemetry::sdk::resource::ResourceAttributes{ {"service.name", "Test OTel"} };
    auto resource_ptr = opentelemetry::sdk::resource::Resource::Create(resource_attributes);

    std::unique_ptr<opentelemetry::sdk::trace::TracerContext> context =
      opentelemetry::sdk::trace::TracerContextFactory::Create(std::move(processors), resource_ptr);

    auto traceProvider = opentelemetry::sdk::trace::TracerProviderFactory::Create(std::move(context));
    auto tracer = traceProvider->GetTracer("OTel-Tracer-Foo");
    auto spanFoo = tracer->StartSpan("Span-Foo");

    tracer = traceProvider->GetTracer("OTel-Tracer-Bar");
    auto spanBar = tracer->StartSpan("Span-Bar");
    spanFoo->End();
    spanBar->End();
  }

Screenshot (No Crash)

[marcalff]

Thanks for the report.

From code review, it seems the problem is in:

exporters/etw/include/opentelemetry/exporters/etw/etw_tracer.h

Attribute Tracer &owner_; is a reference, which points to a dead object by the time the second span ends.

This is because:

  void TestEtwTracer()
  {
    auto traceProvider = std::make_unique<opentelemetry::exporter::etw::TracerProvider>();
1:    auto tracer = traceProvider->GetTracer("Geneva-Tracer-Foo");
    auto spanFoo = tracer->StartSpan("Span-Foo");
2:    tracer = traceProvider->GetTracer("Geneva-Tracer-Bar");
    auto spanBar = tracer->StartSpan("Span-Bar");
    spanFoo->End();
    spanBar->End();
  }

When line 2 is executed, the tracer object from line 1 is released, since nothing keeps a shared pointer on it.

Span::owner_ should be a shared pointer instead, so the link to the tracer is preserved.

[github-actions]

This issue is available for anyone to work on. Make sure to reference this issue in your pull request.
✨ Thank you for your contribution! ✨

[v4xsh]

Thanks for the analysis, this makes sense.

The crash appears to be caused by Span holding a reference (Tracer &owner_)
to a tracer whose lifetime is not guaranteed once the caller overwrites the
shared_ptr returned by GetTracer(). When the first tracer instance is
released, the span still holds a dangling reference, leading to a use-after-free
when End() is called.

I can work on a fix by updating span ownership to keep the tracer alive
(e.g. replacing the reference with shared ownership) and verify the behavior
with the provided reproduction. I’ll open a PR once ready.

[ThomsonTan]

While the issue is valid, I think Tracer should not be destructed before the spans it created.

The fix likely involves more than just changing Tracer &owner_ to std::shared_ptr<Tracer> — there are related lifetime relationships (e.g., Tracer holding a reference to TracerProvider) that should be reviewed as part of the same effort.

Before proceeding, I'd like to verify whether this breaks real-world usage patterns and whether it should be included in the upcoming release or handled separately.

[v4xsh]

Thanks for calling this out — that’s a valid and important concern.

I agree this shouldn’t be treated as a narrow fix. The crash highlights a broader lifetime assumption between Tracer, Span, and TracerProvider that needs careful review.

Before opening a PR, I’ll:

• Review the intended lifetime guarantees across TracerProvider → Tracer → Span
• Check whether other exporters rely on similar ownership assumptions
• Validate how this aligns with real-world usage patterns

I’ll share my findings here first and then propose a fix that preserves correct lifetimes without introducing unintended side effects.