0

I understand that starting from .net2.0 StackOverflowException is no longer catch-able. But people mentioned the exception to the rule when CLR is hosted, in which case it's possible to handle and recover from such exception.

This makes sense because I'm hosting CLR to execute managed code / script in a native service, and I don't want sloppy script code to terminate my service. Instead I would like to be able to recover from such event and blacklist the misbehaving script code from that point on.

But I didn't find much elaborate information regarding how to do so.

Notes: [1] I'm using C++/CLI mixed-assembly as a bridging dll to connect my native service to dotnet, instead of "explicitly hosting CLR" using its COM interfaces.

Weipeng
  • 1,494
  • 14
  • 11
  • Destroy and re-create the AppDomain? – PepitoSh Jul 10 '18 at 01:48
  • @PepitoSh I'm using C++/CLI mixed-assembly as a bridging dll to connect my native service to dotnet, and due to performance reasons the managed code is run in default app domain, so I suppose I can't destroy & re-create default appdomain? – Weipeng Jul 10 '18 at 02:00
  • The simplest solution is don't write code that uses up the stack.. instead of trying to work around the issues, if you can, try to solve it at the source – TheGeneral Jul 10 '18 at 02:04
  • If stack overflow is not due to a bug but you really need a larger stack, you could adjust the size of it in advance. See details: https://stackoverflow.com/questions/2556938/how-to-change-stack-size-for-a-net-program – PepitoSh Jul 10 '18 at 02:17
  • @TheGeneral the thing is I dont control the script source – Weipeng Jul 10 '18 at 05:18
  • @PepitoSh my need is for the host process to be resilient even against code bugs fron thirdparty scripts – Weipeng Jul 10 '18 at 05:20
  • Since Gödel we know for sure that your efforts are in vain. ;-) – PepitoSh Jul 10 '18 at 05:23
  • 5
    If you're sneaking in access to the CLR via C++/CLI, you aren't really hosting the CLR yourself, you don't get access to the CLR hosting options. Instead you're just forcing the self-hosting CLR to be loaded in your process. No shortcuts - if you want to *host* the CLR then you need to do all of the work of actually hosting it. – Damien_The_Unbeliever Jul 10 '18 at 07:06

1 Answers1

0

I don't know to what extent this will work with .NET Framework (whether actually self-hosted or using C++/CLI), but consider using Win32's _resetstkoflw().

In short - your program should call _resetstkoflw() inside an SEH __except handler (this is not the same as a C++ catch block and _resetstkoflw() must never be called from a C++ exception handler!) - this assumes the affected thread in your program starts inside C/C++/native code before entering the CLR instead of being a CLR-created thread and that is the thread that overflows.

I don't know how you could use _resetstkoflw() on a CLR-created thread, however. Perhaps you could intercept every created thread and call-into C/C++/native code that sets-up the SEH __try/__except block and then re-enters the CLR inside the __try? (Assuming that the interception of the creation of managed threads is even possible).

Dai
  • 141,631
  • 28
  • 261
  • 374