Limit deep stack growth #4156
Limit deep stack growth #4156
Conversation
jcheng5
force-pushed
the
deep-stack-limit
branch
from
13f79ff to
8024897
Compare
- Keep around the first deep stack trace; it may have useful information. (We may want to change this in the future to keep the first two stack traces, or even make it an option) - Print out an indicator that we've elided stack traces, and how many
jcheng5
force-pushed
the
deep-stack-limit
branch
from
508b4dd to
3f49835
Compare
Co-authored-by: Carson Sievert <cpsievert1@gmail.com>
Co-authored-by: Carson Sievert <cpsievert1@gmail.com>
This hopefully will avoid any potential ..stacktraceon../off.. scoring issues, and will be more useful for users. The downside is that it's still possible to have uselessly large deep stack traces, but at least that will only happen now if you have manually written gigantic async/promise chains by hand or maybe did some clever metaprogramming. The coro case should be fine.
|
After an in-person discussion with @cpsievert and @gadenbuie yesterday, we decided to use a different approach to limiting deep stack growth: rather than dropping deep stacks beyond a certain number, we only keep unique call stacks (determined by comparing Currently, we're simply keeping the first unique of each call stack. It would also be conceivable to limit the culling to consecutive duplicates, or to open up slightly from that and detect consecutive duplicate series of call stacks (for example, |
|
@cpsievert @gadenbuie was this too paranoid? d4f144d |
It does seem like overkill if we're just hashing character vectors, but if we end up doing something like #4156 (comment), then it seems worth doing. |
Co-authored-by: Carson Sievert <cpsievert1@gmail.com>
Related to /~https://github.com/jcheng5/shinychat/issues/16