Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[browser][MT] Log ManagedThreadId and NativeThreadId for known test failures #98291

Merged
merged 5 commits into from
Feb 22, 2024

Conversation

mkhamoyan
Copy link
Contributor

Log ManagedThreadId and NativeThreadId for following test failures
#98101, #98216, #97914

Once test failures will be fixed, we will remove these logs.

@mkhamoyan mkhamoyan added arch-wasm WebAssembly architecture os-browser Browser variant of arch-wasm labels Feb 12, 2024
@mkhamoyan mkhamoyan self-assigned this Feb 12, 2024
@ghost
Copy link

ghost commented Feb 12, 2024

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Log ManagedThreadId and NativeThreadId for following test failures
#98101, #98216, #97914

Once test failures will be fixed, we will remove these logs.

Author: mkhamoyan
Assignees: mkhamoyan
Labels:

arch-wasm, os-browser

Milestone: -

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -376,6 +377,7 @@ public async Task ThreadingTimer(Executor executor)
await tcs.Task;
}, cts.Token);

Console.WriteLine("ThreadingTimer: ManagedThreadId: " + Environment.CurrentManagedThreadId + " NativeThreadId: " + WebWorkerTestHelper.NativeThreadId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebWorkerTest.ThreadingTimer didn't hit at all in the log. So it would be also good to print timestamp before (line 367) and after (380)

Maybe we just need to move hit = true; before tcs.SetResult(); on line 374, because that's race conditon in the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated this part accordingly.

@@ -451,7 +453,7 @@ public async Task WaitAssertsOnJSInteropThreads(Executor executor, NamedCall met
{
exception = ex;
}

Console.WriteLine("WaitAssertsOnJSInteropThreads: ManagedThreadId: " + Environment.CurrentManagedThreadId + " NativeThreadId: " + WebWorkerTestHelper.NativeThreadId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would this tell us which and why Value is null ? #97914

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, we know which exception, we don't know why.

The "why" is likely because the call is executed on different thread than we expected.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could also be the "why"

This code is swallowing OperationCanceledException instead of passing it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added logs to validate if that is the case.

@@ -82,6 +82,7 @@ public async Task HttpClient_CancelInDifferentThread(Executor executor1, Executo
{
CancellationTokenSource cts = new CancellationTokenSource();
var promise = response.Content.ReadAsStringAsync(cts.Token);
Console.WriteLine("HttpClient_CancelInDifferentThread: ManagedThreadId: " + Environment.CurrentManagedThreadId + " NativeThreadId: " + WebWorkerTestHelper.NativeThreadId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use ThrowsAnyAsync<OperationCanceledException> on line 81 may hide the problem.
The question is why we have 2 different code paths.

Please log stack traces in both cases, so that we could compare them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept ThrowsAsync<TaskCanceledException>, so issue will still happen but added logs to see stack traces for both TaskCanceledException and OperationCanceledException.

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -156,14 +156,20 @@ public class NamedCall
using var cts = new CancellationTokenSource(8);
try {
mr.Wait(cts.Token);
} catch (OperationCanceledException) { /* ignore */ }
} catch (OperationCanceledException) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should not be swallowed I think. Because it's not really the expected outcome.
If it was expected outcome, the outer assert should process that case, rather than misleading null, which for this test means that something is broken for Main and WebWorker executors.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to not swallow OperationCanceledException.

@mkhamoyan
Copy link
Contributor Author

/azp run runtime-wasm

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -156,14 +156,24 @@ public class NamedCall
using var cts = new CancellationTokenSource(8);
try {
mr.Wait(cts.Token);
} catch (OperationCanceledException) { /* ignore */ }
} catch (Exception ex) {
if (ex is OperationCanceledException)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Radek's solution here is bit better #98508 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed these changes.

Copy link
Member

@pavelsavara pavelsavara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please observe the outcome and let us know what we learned from it. Thank you!

@mkhamoyan mkhamoyan merged commit 8dcb639 into dotnet:main Feb 22, 2024
44 of 106 checks passed
@mkhamoyan mkhamoyan deleted the known_issue_logs branch February 22, 2024 10:57
@github-actions github-actions bot locked and limited conversation to collaborators Mar 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript os-browser Browser variant of arch-wasm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants