Open kjvalencik opened 3 years ago
Thanks for reporting this. Can you include a backtrace for this? I have a suspicion as to what's happening here, but it'd be good to get confirmation via a backtrace.
It's a very large backtrace. I included the top 1000 lines. Let me know if the entire backtrace would be useful.
The EXC_BAD_ACCESS
is because it's overflowing the stack guard. It will fail at a fairly arbitrary section of the code depending on the size of the spans and other stack usage. I can also try reproducing with a smaller stack size.
Edit: Here's a full backtrace with --release
and my stack size set to 128
.
Still very much a problem I believe! I've submitted a reproducible test here: https://github.com/tokio-rs/tracing/pull/2199.
I can potentially work on a fix, but, a) no promises :), and, b) I would appreciate a pointer to where exactly I should add a "drop a tree of parents in a loop" code.
Although, taking a step back here:
The reason why we were hitting stack overflows is because we had buggy code which created infinitedely deep span trees. The bug was similar to https://onesignal.com/blog/solving-memory-leaks-in-rust/.
So perhaps a fix for that problem would be for tracing too emit some kind of error event if it detects an unreasonably deep span tree?
Bug Report
tracing-subscriber
with theregistry
feature enabled causes a stack overflow when recursively dropping deeply nested spans.Version
Platform
macOS 11.1
Crates
tracing-subscriber
withregistry
featureDescription
Release requires more depth, presumably because of optimized stack usage, but still overflows.
I had this issue in recursive
async
code. Because ofasync
and heap allocation, stack overflow was not an issue for the untraced code, but was with tracing enabled.