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

[viewizard]

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

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

Actual behavior

1. During evaluation call ICorDebugEval::Abort or ICorDebugEval2::RudeAbort, it will return S_OK.
2. Evaluated code continue execution.
3. 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

[viewizard]

CC @alpencolt

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

1. During evaluation call ICorDebugEval::Abort or ICorDebugEval2::RudeAbort, it will return S_OK.
2. Evaluated code don't continue execution.
3. ICorDebugManagedCallback::EvalComplete or ICorDebugManagedCallback::EvalException called.

Actual behavior

1. During evaluation call ICorDebugEval::Abort or ICorDebugEval2::RudeAbort, it will return S_OK.
2. Evaluated code continue execution.
3. After evaluated code execution ends ICorDebugManagedCallback::EvalComplete or ICorDebugManagedCallback::EvalException called. 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

Author:	viewizard
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[gbalykov]

cc @jkotas

[gbalykov]

@jkotas did you have a chance to take a look?

[jkotas]

Looks like a regression, it may be related to #71661. @tommcdon Do you see this problem in VS debugger tests?

[tommcdon]

This may be related to #72705 and if 'yes' it could be a duplicate to #72703. I am not seeing any issues in our Visual Studio func-eval abort testing on .NET 7 or .NET 8 running against Linux and macOS.
@viewizard would it be possible to share a reproducible test case of the debuggee function failing to abort?

[viewizard]

I just figure out, that in case some simple test all works fine on Linux amd64 with VSCode debugger and our debugger too. For example, simple test like:

using System;

namespace test
{
    class Program
    {
        static int eval_test()
        {
            //System.Diagnostics.Debugger.NotifyOfCrossThreadDependency();
            System.Threading.Thread.Sleep(20000);
            return 5;
        }

        static void Main()
        {
            int i = 0;
            i ++;
        }
    }
}

with evaluation for eval_test() at line i++ will properly abort since timed out.
In case of our debugger, it will also abort without any issues in case NotifyOfCrossThreadDependency will uncomment.

But it fails on our complex eval tests we do at lines (note, Label.Checkpoint blocks is parts related of control program, that interact with debugger, other code - debuggee program related code):
https://github.com/Samsung/netcoredbg/blob/master/test-suite/MITestVariables/Program.cs#L1197
https://github.com/Samsung/netcoredbg/blob/master/test-suite/MITestEvaluate/Program.cs#L1453
https://github.com/Samsung/netcoredbg/blob/master/test-suite/VSCodeTestVariables/Program.cs#L1315
https://github.com/Samsung/netcoredbg/blob/master/test-suite/VSCodeTestEvaluate/Program.cs#L1577
all the time, Abort() return S_OK:
https://github.com/Samsung/netcoredbg/blob/fb63fd9a834a3f640bc573827bf50c142ee5039b/src/debugger/evalwaiter.cpp#L241
https://github.com/Samsung/netcoredbg/blob/fb63fd9a834a3f640bc573827bf50c142ee5039b/src/debugger/evalwaiter.cpp#L183

as you could see we do a lot of evals before abort-related test, probably this is related (unfortunately I was not able to reproduce this with some simple code in VSCode).
If you would like, I could provide instruction how you could use our debugger on Linux in order to run this tests.

[tommcdon]

Thanks for taking a look @viewizard! Would you mind explaining what GetAndCheckValue and CheckErrorAtRequest does? I'm guessing it performs a func-eval. So if I am reading the code correctly, it seems the order events are:

1. func-eval stGetInt()
2. func-eval stGetInt(333)
3. func-eval getInt()
4. func-eval TestTimeOut()

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?

https://github.com/Samsung/netcoredbg/blob/db69338cf1606d8d327de0eaaf1694d8463af135/test-suite/VSCodeTestEvaluate/Program.cs#L801-L805

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.

[viewizard]

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.