Commit a994110
[EXPORTER ETW] Fix Span::End() use-after-free when caller drops Tracer
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<Tracer> 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.
While putting this together I tripped over a second bug that the
cache exposes -- worth describing here because the fix lives in the
same file.
etw_tracer.h and etw_provider.h between them have three independent
function-local statics that get tangled at process shutdown:
1. etw::TracerProvider itself (now owning the tracer cache).
2. Tracer::etwProvider() returns a `static ETWProvider instance`.
3. ETWProvider::providers() returns a `static std::map<...> providers`
that lives inside that singleton's method, not inside the
singleton object, and is lazily created on the first
open()/is_registered() call.
Before this change, all three were initialized in that order on the
very first GetTracer() call: the TracerProvider was already
constructed, then the Tracer ctor called etwProvider().open(...),
which constructed #2 and #3. Reverse-order destruction therefore took
out #3 first, while the TracerProvider (and its cached Tracers, which
hold references into #3) was still alive. ~Tracer then ran
etwProvider().close(provHandle) against a dangling reference and we
got an AV at exit. With the old "fresh Tracer per call, caller drops
it immediately" pattern this was hidden because the Tracer (and its
provHandle reference) was almost always gone long before shutdown.
The cache extends Tracer lifetime to match TracerProvider lifetime,
which is exactly what tripped this over locally and on the Windows
CI legs.
The fix is small: both TracerProvider constructors now do
(void)Tracer::etwProvider().is_registered(std::string{});
which forces both ETWProvider singletons to be constructed before the
TracerProvider's body finishes. Reverse destruction then guarantees
they outlive the cached Tracers. is_registered() is a public, side-
effect-free read on ETWProvider that internally touches the providers
map, which is exactly the static-init we need. It requires Tracer to
befriend TracerProvider so the constructor can call the private
etwProvider() accessor.
A few things worth calling out:
- No API or ABI change. Only private members are added to
TracerProvider, and <map>/<memory>/<mutex> are already included by
etw_tracer.h. The friend declaration is purely internal.
- 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
currently cache Loggers, so the destruction-order fix is not needed
there today. If a similar cache is ever added to LoggerProvider it
will want the same one-line force-init in its constructor.
- Updated ETWTracer.GlobalSingletonTracer: it previously asserted that
two GetTracer() calls with the same provider name produce different
trace ids, which only held because of the bug being fixed here.
GetTracer(name) is now idempotent per name, so the assertion is
flipped to EXPECT_EQ and the stale sample-event comment updated to
match. All other ETW tracer tests continue to pass.
Repro before the change: AV in Span::End with the freed-fill operand,
plus exit-time AV in ~Tracer on ctest runs that exercise a single
test in isolation. Same repros after: both run cleanly to completion.
Verified locally with the full ctest suite on a Windows abiv2
maintainer-mode build (1104/1104 passing) and on an abiv1 Debug build
(43/43 ETW tests passing).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>1 parent 72953ea commit a994110
2 files changed
Lines changed: 70 additions & 7 deletions
Lines changed: 64 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
169 | 169 | | |
170 | 170 | | |
171 | 171 | | |
| 172 | + | |
| 173 | + | |
| 174 | + | |
| 175 | + | |
172 | 176 | | |
173 | 177 | | |
174 | 178 | | |
| |||
1106 | 1110 | | |
1107 | 1111 | | |
1108 | 1112 | | |
| 1113 | + | |
| 1114 | + | |
| 1115 | + | |
| 1116 | + | |
| 1117 | + | |
| 1118 | + | |
| 1119 | + | |
| 1120 | + | |
| 1121 | + | |
| 1122 | + | |
| 1123 | + | |
1109 | 1124 | | |
1110 | 1125 | | |
1111 | 1126 | | |
| |||
1143 | 1158 | | |
1144 | 1159 | | |
1145 | 1160 | | |
| 1161 | + | |
| 1162 | + | |
| 1163 | + | |
| 1164 | + | |
| 1165 | + | |
| 1166 | + | |
| 1167 | + | |
| 1168 | + | |
| 1169 | + | |
| 1170 | + | |
| 1171 | + | |
1146 | 1172 | | |
1147 | 1173 | | |
1148 | 1174 | | |
| |||
1152 | 1178 | | |
1153 | 1179 | | |
1154 | 1180 | | |
| 1181 | + | |
| 1182 | + | |
| 1183 | + | |
| 1184 | + | |
| 1185 | + | |
| 1186 | + | |
| 1187 | + | |
| 1188 | + | |
| 1189 | + | |
| 1190 | + | |
| 1191 | + | |
| 1192 | + | |
| 1193 | + | |
| 1194 | + | |
| 1195 | + | |
| 1196 | + | |
| 1197 | + | |
| 1198 | + | |
| 1199 | + | |
| 1200 | + | |
| 1201 | + | |
| 1202 | + | |
| 1203 | + | |
| 1204 | + | |
| 1205 | + | |
1155 | 1206 | | |
1156 | 1207 | | |
1157 | 1208 | | |
| |||
1177 | 1228 | | |
1178 | 1229 | | |
1179 | 1230 | | |
1180 | | - | |
1181 | | - | |
1182 | | - | |
| 1231 | + | |
| 1232 | + | |
| 1233 | + | |
| 1234 | + | |
| 1235 | + | |
| 1236 | + | |
| 1237 | + | |
| 1238 | + | |
| 1239 | + | |
| 1240 | + | |
| 1241 | + | |
| 1242 | + | |
| 1243 | + | |
1183 | 1244 | | |
1184 | 1245 | | |
1185 | 1246 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
392 | 392 | | |
393 | 393 | | |
394 | 394 | | |
395 | | - | |
| 395 | + | |
| 396 | + | |
| 397 | + | |
396 | 398 | | |
397 | 399 | | |
398 | 400 | | |
399 | 401 | | |
400 | | - | |
| 402 | + | |
401 | 403 | | |
402 | 404 | | |
403 | 405 | | |
| |||
418 | 420 | | |
419 | 421 | | |
420 | 422 | | |
421 | | - | |
| 423 | + | |
422 | 424 | | |
423 | 425 | | |
424 | 426 | | |
| |||
455 | 457 | | |
456 | 458 | | |
457 | 459 | | |
458 | | - | |
| 460 | + | |
459 | 461 | | |
460 | 462 | | |
461 | 463 | | |
| |||
0 commit comments