Breaking on stack overflow

[markolbert]

In the course of using xUnit I sometimes run into situations where there's a self-referencing bug in my code which causes a stack overflow. This is when using xUnit within VS 2019 (latest updates installed).

The bug is obviously my fault...but finding it is complicated by the fact the overflow doesn't manifest itself as a stack overflow. Instead, what eventually happens is the test crashes with an Access Violation. No exception is ever caught before this happens, even when I configure VS to not attempt to handle any exceptions.

Why is this happening? Is there a way to configure xUnit so it does catch/throw overflow exceptions? I've noticed it handles other kinds of exceptions (e.g., ones thrown by Autofac when the DI container can't resolve a component).

• Mark

[tullo-x86]

Well first off, you can only ever catch a StackOverflowException if you're the one who threw it.

Secondly, wow, I've never seen .NET terminate with an access violation. That's your OS dropping the hammer on .NET for touching memory that it doesn't own. You have no chance to recover from this, but you might be able to use a profiler (in instrumentation mode) to figure out where your execution was during the lead-up to the access violation.

[markolbert]

Interesting. I wonder why I occasionally see stack overflow exceptions when I'm debugging (i.e., and not when I've thrown them specifically).

Thanx for the feedback.

[tullo-x86]

The debugger will notify you of a stack overflow and pause execution, but recovering from that state (including catching the exception) is impossible. Try dragging the execution pointer around in Visual Studio on a StackOverflowException: you can't. Because the runtime is in an unrecoverable state at that point, and all the debugger can do is show you what's in memory until you're ready to terminate the process.