[EXPORTER ETW] Fix Span::End() use-after-free when caller drops Tracer

[lukeina2z]

Fixes #3849.

etw::TracerProvider::GetTracer() was newing up a fresh Tracer per call and returning the only shared_ptr to it. The catch is that etw::Span stores its parent as a raw reference (Tracer &owner_), so the moment a caller drops or reassigns that shared_ptr, every Span that came from that Tracer is left with a dangling owner_. Span::End() then crashes inside owner_.EndSpan().

The snippet from the issue makes it obvious:

auto provider = std::make_unique<etw::TracerProvider>();
auto tracer   = provider->GetTracer("Foo");
auto spanFoo  = tracer->StartSpan("Span-Foo");
tracer        = provider->GetTracer("Bar");  // Tracer "Foo" goes away
auto spanBar  = tracer->StartSpan("Span-Bar");
spanFoo->End();                              // crash
spanBar->End();

Under MSVC Debug + cdb this lands as an AV in Span::End dereferencing 0xFEEEFEEE -- the debug heap's freed-memory fill -- which is about as unambiguous as UAF gets.

The fix is to let TracerProvider keep the Tracers it hands out, keyed by name and guarded by a mutex, and have GetTracer() return the cached entry on repeat calls. That makes the Tracer outlive any Span derived from it, which is the lifetime contract Span's raw owner_ already assumes. It is also the same pattern sdk::trace::TracerProvider has always used, which is why the issue reporter noted the SDK provider does not crash under the same usage.

There was an earlier attempt in PR #4070 that switched Span to take a shared_ptr via shared_from_this(). That was turned down because StartSpan() is the ETW exporter's hot path and nobody wants an extra atomic refcount bump on every span just to keep the parent alive. Doing the lifetime work once in GetTracer() keeps owner_ as a plain reference and costs nothing per span.

A few things worth calling out:

• No API or ABI change. Only private members are added to TracerProvider, and // are already included by etw_tracer.h.
• The cache deliberately does not evict. Span holds its parent by raw reference, so dropping a Tracer that still has live Spans would put the original bug right back. In practice the ETW exporter is built around "one Tracer per provider name, reused for the lifetime of the process", and Windows itself caps registered ETW providers per process well below anything you would worry about for memory.
• Keying on name only is consistent with the existing etw::Tracer constructor, which already declares args and schema_url UNREFERENCED_PARAMETER.
• etw::LoggerProvider was checked for the same shape and does not have it -- Logger holds a back-reference to the Provider (long-lived), not to itself -- so no equivalent change is needed there.

Repro before the change: AV in Span::End with the freed-fill operand.
Same repro after: runs cleanly to completion.

Fixes # (issue)

Changes

Please provide a brief description of the changes here.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.15%. Comparing base (7a38ec8) to head (9021289).
⚠️ Report is 42 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4100      +/-   ##
==========================================
+ Coverage   81.14%   81.15%   +0.02%     
==========================================
  Files         446      446              
  Lines       18922    18922              
==========================================
+ Hits        15353    15355       +2     
+ Misses       3569     3567       -2     

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marcalff]

@lalitb @ThomsonTan

This is related to ETW, please take a look.

Thanks.

[ThomsonTan]

This cache-hit condition only checks whether an entry exists, not whether the cached Tracer is still usable. In ABI v1, CloseWithMicroseconds() marks it closed, and ETWProvider::close() erases its Handle node when the refcount reaches zero. The cached Tracer then retains a dangling provHandle reference.

auto t1 = tp.GetTracer("Foo");
t1->CloseWithMicroseconds(0);
auto t2 = tp.GetTracer("Foo");  // same closed Tracer
t2->StartSpan("s")->End();      // writes through dangling provHandle

Please treat a closed cache hit as a miss: retain the old Tracer so existing Spans keep their owner, cache a fresh Tracer, and make writes from the retired/closed Tracer return before touching provHandle (or otherwise keep the Handle node stable). Please add this exact close/reacquire/end sequence as a regression test.

[ThomsonTan]

The scope is per TracerProvider, not process-wide, but this cache still locks in incorrect root-span correlation. traceId_ is generated once in the ETW Tracer constructor, and StartSpan() reuses it whenever there is no valid parent. Returning the same cached Tracer therefore gives two independent root spans the same TraceId:

auto tracer = tp.GetTracer("Foo");
auto a = tracer->StartSpan("a");
auto b = tracer->StartSpan("b");
EXPECT_NE(a->GetContext().trace_id(), b->GetContext().trace_id());

The OpenTelemetry specification requires a new TraceId for every root span. This was already the ETW bug reported in #3846, caching removes the previous GetTracer() workaround, while the changed EXPECT_EQ assertion pins the wrong behavior.

Please keep the lifetime cache, but generate a new TraceId inside StartSpan() whenever the parent is invalid, and inherit the parent's TraceId otherwise. Please restore the distinct-root assertion and add a child-span inheritance test.

[dbarker]

@lukeina2z Are you still interested in contributing this change? Please see feedback from Tom above.