runtime: [Linux, amd64] ICorDebugEval::Abort are broken.

Description

During netcoredbg testing with .NET SDK 7.0 (dotnet-sdk-7.0.200-linux-x64.tar.gz). We found, that tests related to evaluation abort (timeout during execution and System.Diagnostics.Debugger.NotifyOfCrossThreadDependency() usage in evaluated code) are failed. We found, that ICorDebugEval::Abort and ICorDebugEval2::RudeAbort return S_OK at call, but don’t really abort evaluation in 7.0 (we also tested latest .NET SDK 3.1, 5.0, 6.0 and don’t found any issues).

Reproduction Steps

Call ICorDebugEval::Abort in debugger. For example, create property with getter with System.Diagnostics.Debugger.NotifyOfCrossThreadDependency() and evaluate it. In this case runtime will call ICorDebugManagedCallback3::CustomNotification that forced debugger to use ICorDebugEval::Abort (CoreCLR debug API don’t really provide any other way you could abort code execution during evaluation).

Expected behavior

During evaluation call ICorDebugEval::Abort or ICorDebugEval2::RudeAbort, it will return S_OK.
Evaluated code don’t continue execution.
ICorDebugManagedCallback::EvalComplete or ICorDebugManagedCallback::EvalException called, ICorDebugEval::GetResult() return CORDBG_S_FUNC_EVAL_ABORTED.

Actual behavior

During evaluation call ICorDebugEval::Abort or ICorDebugEval2::RudeAbort, it will return S_OK.
Evaluated code continue execution.
After evaluated code execution ends ICorDebugManagedCallback::EvalComplete or ICorDebugManagedCallback::EvalException called, ICorDebugEval::GetResult() return S_OK. In case evaluated code never ends (for example, about deadlock), ICorDebugManagedCallback::EvalComplete or ICorDebugManagedCallback::EvalException never called.

Regression?

It works fine on Linux amd64 with .NET SDK 3.1, 5.0 and 6.0.

Known Workarounds

No response

Configuration

Ubuntu 20.04 amd64, .NET SDK 7.0 (dotnet-sdk-7.0.200-linux-x64.tar.gz).

Other information

No response

About this issue

Original URL
State: open
Created a year ago
Comments: 25 (25 by maintainers)

Commits related to this issue

Temporary fix for Abort() related CoreCLR 7.0 tests. CoreCLR 7.0 have issue with abortable internal native code. https://github.com/dotnet/runtime/issues/82422 — committed to Samsung/netcoredbg by viewizard a year ago
Apply eval abort test fix for CLR 8.0. Related to https://github.com/dotnet/runtime/issues/82422 — committed to Samsung/netcoredbg by viewizard 9 months ago

Most upvoted comments

Yes, GetAndCheckValue and CheckErrorAtRequest send to debugger EvaluateRequest and wait for reply, for GetAndCheckValue we compare it with ExpectedResult and ExpectedType.

it seems the order events are: func-eval stGetInt() func-eval stGetInt(333) func-eval getInt() func-eval TestTimeOut()

You absolutely right, but I was not able to reproduce abort-related issue with only this evals tests, this looks strange for me, since we do only this tests on current breakpoint stop.

Is this the TestTimeOut() function the one that fails to Abort()? It seems it sleeps for 10 seconds then returns. How long does the test wait for the abort to occur?

debugger will call Abort() after 5 sec - https://github.com/Samsung/netcoredbg/blob/fb63fd9a834a3f640bc573827bf50c142ee5039b/src/debugger/evalwaiter.cpp#L167 but Abort() do nothing and eval-related code continue executing, debugger wait for eval ends here: https://github.com/Samsung/netcoredbg/blob/fb63fd9a834a3f640bc573827bf50c142ee5039b/src/debugger/evalwaiter.cpp#L193 In case VSCodeTestEvaluate, after 10 seconds (System.Threading.Thread.Sleep(10000); ends) eval will complete (ICorDebugManagedCallback::EvalComplete() will be called with result) and debugger provide “result” = 5, that should not happens (should ends without result).

If we selectively comment out different parts of the test, does the Abort eventually begin to succeed? If ‘yes’ then I suggest systematically un-commenting test code until we find the previous step that causes the Abort to fail. It may be that something before the func-eval abort is causing the debugger or the runtime to be destabilized and leads to the func-eval abort failure.

Sure, I will try in monday find some related eval block.

viewizard on Apr 7, 2023