exception-breakpoints: allow filtering out 'internal' excetpions

[noam-sol]

Hey,
We've noticed that when 'all' is selected from ['all', 'user-unhandled'] in vscode exceptions, then it also breaks on exceptions which their entire path ('throw' to the handler) is internal to libs, which lead to some noise when debugging.

I'd like to add the ability to filter those out, probably by calling EnableExceptionCallbacksOutsideOfMyCode(false). Should it be default in vscode's "all", or maybe a new option? I'm not sure. Any ideas?

• docs: https://learn.microsoft.com/en-us/dotnet/framework/unmanaged-api/debugging/icordebugprocess8-enableexceptioncallbacksoutsideofmycode-method#syntax

• Also, I already found a reference in a code comment - https://github.com/rafttio/netcoredbg/blob/8c14d48c49800f47d0297c90ece004e45ac3533d/src/debugger/breakpoints_exception.cpp#L333
  I'm not sure if there's any reasoning behind it not being supported at the moment.

[viewizard]

1. If I remember correct, we don't implement this because of issues with thread status tracking for some cases and this need more time for investigation. Imho, if you can't guarantee that you will care about all around, best solution will be keep proper tracking but don't emit stop event in this case for 2 cases covered by EnableExceptionCallbacksOutsideOfMyCode(false) (DEBUG_EXCEPTION_FIRST_CHANCE and DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_CATCH_HANDLER_FOUND) instead of EnableExceptionCallbacksOutsideOfMyCode(false) usage itself.
2. Runtume could have second internal unhandled exception during work with exception (out of memory, for example), that will mean debugger will never know initial exception and/or related to it data:
   should be (normal):
   DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_USER_FIRST_CHANCE -> DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
   will be (out of memory in runtime):
   DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_UNHANDLED
   will be (out of memory in runtime) + EnableExceptionCallbacksOutsideOfMyCode(false) :
   DEBUG_EXCEPTION_UNHANDLED
3. This should work with JMC enabled by user only (since debuggers use JMC internally all the time for stepping and more).

Should it be default in vscode's "all", or maybe a new option?

We keep same default behaviour as MS debuggers. Is vsdbg behaviour was changed? Probably, since this should work for all protocols, make it with env, that ExceptionBreakpoints class constructor read and care about logic.

[noam-sol]

issues with thread status tracking

@viewizard can you share some details about what could go wrong? I'm starting to get into the codebase and I'd love to hear about all these edge cases. Thanks!

I mean, each exception starts with FIRST_CHANCE, so the thread state would be reset for any time a relevant exception is thrown, right?

[viewizard]

can you share some details about what could go wrong?

That was about 3 years ago when I refactor exception breakpoints, and this case was not even analyzed carefully (since we decided to skip it from implementation at early stage). Unfortunately, I have nothing to add to my previous post now.

I mean, each exception starts with FIRST_CHANCE, so the thread state would be reset for any time a relevant exception is thrown, right?

This is not so simple. :-)
See my comment with runtime callback calls logic and current implemented debugger logic:

netcoredbg/src/debugger/breakpoints_exception.cpp

Lines 329 to 360 in db69338

	DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
	enabled JMC: throw none (reset thread status)
	disabled JMC: throw none (reset thread status)
	* case with ICorDebugProcess8::EnableExceptionCallbacksOutsideOfMyCode(FALSE), not used in our debugger, but must be included
	DEBUG_EXCEPTION_USER_FIRST_CHANCE -> DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
	enabled JMC: throw [outside JMC] user-unhandled (reset thread status)
	[inside JMC] none (reset thread status)
	disabled JMC: throw none (reset thread status)
	DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_USER_FIRST_CHANCE -> DEBUG_EXCEPTION_CATCH_HANDLER_FOUND
	enabled JMC: throw none [outside JMC] user-unhandled (reset thread status)
	[inside JMC] none (reset thread status)
	disabled JMC: throw none none (reset thread status)
	* fatal exception from runtime itself
	DEBUG_EXCEPTION_UNHANDLED
	enabled JMC: unhandled (reset thread status)
	disabled JMC: unhandled (reset thread status)
	DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_UNHANDLED
	enabled JMC: throw unhandled (reset thread status)
	disabled JMC: throw unhandled (reset thread status)
	* case with ICorDebugProcess8::EnableExceptionCallbacksOutsideOfMyCode(FALSE), not used in our debugger, but must be included
	DEBUG_EXCEPTION_USER_FIRST_CHANCE -> DEBUG_EXCEPTION_UNHANDLED
	enabled JMC: throw unhandled (reset thread status)
	disabled JMC: throw unhandled (reset thread status)
	DEBUG_EXCEPTION_FIRST_CHANCE -> DEBUG_EXCEPTION_USER_FIRST_CHANCE -> DEBUG_EXCEPTION_UNHANDLED
	enabled JMC: throw none unhandled (reset thread status)
	disabled JMC: throw none unhandled (reset thread status)

In short: exception could start with DEBUG_EXCEPTION_FIRST_CHANCE, DEBUG_EXCEPTION_USER_FIRST_CHANCE or DEBUG_EXCEPTION_UNHANDLED. Only in case first (start) exception callback call you could get initial exception related data (sure, this also could be done with evaluation of exception managed object if... if you able to evaluate(execute managed code of property), that could be not possilbe in case of internal runtime fail or some GC related state that will prevent evaluation on thread with exception).