6 ms·

I've run into frustrating stack overflows in seemingly trivial non-recursive code, so I appreciate this effort! I wonder if it might be simpler to track stack

I've run into frustrating stack overflows in seemingly trivial non-recursive code, so I appreciate this effort! I wonder if it might be simpler to track stack sizes statically instead of using runtime instrumentation. What I mean is, for example on x86_64, the function prologue has a stack reservation in the form of `sub rbp, 0x168`. So we can easily tell that the function uses 0x168 bytes of stack space. Just add those numbers up for every function in a crate, and you have a score. Track that number over time for a set of common crates.

bjourne 4y ago
This won't work since you also need to track the maximum number of stack frames (e.g recursive calls) which is undecidable.
Murfalo 4y ago
It's not clear to me how this would track stack<->stack and memory<->stack copies. Can you explain?
- throwup 4y ago
  My suggestion would not measure the copies themselves, but it would count how many bytes are the source/destination of copies (of course incl. other things like parameters/etc). It's not the exact same metric, but it does still help answer the question in the title. I would expect the two numbers to be highly correlated when building the same binary with different versions of the compiler. It would also solve some practical problems mentioned in the page like the complexity of the setup and the speed of statistics gathering.
- toxik 4y ago
  If you copy between stack regions, you need more stack memory, so the stack allocation should be larger. Of course, this would undercount cases that copy to the same region many times which seems likely.
the_mitsuhiko 4y ago
I like tracking this or at least having a way to track this. It's incredibly common that you only discover a crash too late in production due to running out of stack size and at least knowing a histogram over some test runs about how close something went to the (configured) limit would already be incredibly helpful for service stability.

bjourne 4y ago

This won't work since you also need to track the maximum number of stack frames (e.g recursive calls) which is undecidable.

Murfalo 4y ago

It's not clear to me how this would track stack<->stack and memory<->stack copies. Can you explain?

throwup 4y ago
My suggestion would not measure the copies themselves, but it would count how many bytes are the source/destination of copies (of course incl. other things like parameters/etc). It's not the exact same metric, but it does still help answer the question in the title. I would expect the two numbers to be highly correlated when building the same binary with different versions of the compiler. It would also solve some practical problems mentioned in the page like the complexity of the setup and the speed of statistics gathering.
toxik 4y ago
If you copy between stack regions, you need more stack memory, so the stack allocation should be larger. Of course, this would undercount cases that copy to the same region many times which seems likely.

the_mitsuhiko 4y ago

I like tracking this or at least having a way to track this. It's incredibly common that you only discover a crash too late in production due to running out of stack size and at least knowing a histogram over some test runs about how close something went to the (configured) limit would already be incredibly helpful for service stability.