You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Build: 🔎 Result validation:⚠️ Validation could not be done without an Azure DevOps build URL on the issue. Please add it to the "Build: 🔎" line. Validation performed at: 4/25/2024 9:12:24 PM UTC
@lewing I believe I have looked into the original and it was actually not an issue of the new EH, but rather a regular unhandled exception or something along these lines. Unfortunately, the only two remaining failures from the list above are misclassified, so I cannot double check it now.
@jkotas the failure in the referenced run is just an unhandled exception. From the test log:
Output:
Unhandled exception. System.Exception: Profiler tests are expected to contain the text 'PROFILER TEST PASSES' in the console output of the profilee app to indicate a passing test. Usually it is printed from the Shutdown() method of the profiler implementation. This text was not found in the output above.
at Profiler.Tests.ProfilerTestRunner.FailFastWithMessage(String error)
at Profiler.Tests.ProfilerTestRunner.Run(String profileePath, String testName, Guid profilerClsid, String profileeArguments, ProfileeOptions profileeOptions, Dictionary`2 envVars, String reverseServerName, Boolean loadAsNotification, Int32 notificationCopies)
at Profiler.Tests.MultiplyLoaded.Main(String[] args)
The last message from the actual test is
Waiting for profilers to all detach
So that sounds like profiler or test related issue.
Missing volatile that I have added in #101607 can explain failures with these symptoms. I suspect that my change is not going to fix the failures. The test has been failing too frequently for missing volatile to be the root cause of the failures.
I would keep this issue open for 2 weeks. If we do not see any new hits in 2 weeks, we can declare it fixed.
Profiler path: C:\h\w\C29B0A72\w\AB5E08EF\e\profiler\multiple\multiple\Profiler.dll
Profiler path: C:\h\w\C29B0A72\w\AB5E08EF\e\profiler\multiple\multiple\Profiler.dll
Profiler.dll!DllGetClassObject
MultiplyLoaded::Initialize
Profiler.dll!Profiler::Initialize
Profiler.dll!DllGetClassObject
MultiplyLoaded::Initialize
Profiler.dll!Profiler::Initialize
Profiler path: C:\h\w\C29B0A72\w\AB5E08EF\e\profiler\multiple\multiple\Profiler.dll
Profiler.dll!DllGetClassObject
MultiplyLoaded::InitializeForAttach
Profiler.dll!Profiler::Initialize
Throwing exception
Exception caught
Waiting for profilers to all detach
Test failed: Profiler tests are expected to contain the text 'PROFILER TEST PASSES' in the console output of the profilee app to indicate a passing test. Usually it is printed from the Shutdown() method of the profiler implementation. This text was not found in the output above. Profilee returned exit code 100.
Expected: 100
Actual: -532462766
END EXECUTION - FAILED
FAILED
Test failed. Trying to see if dump file was created in C:\cores since 4/30/2024 6:55:01 AM
The profilee returned code 100 which means that the _profilerDone.WaitOne call succeeded, but we should only set the event after seeing all three profilers successfully detach. There are no logs indicating any profiler attached however. My only thought is that somehow we are just missing output from the profiled process, but we call Process.WaitForExit() which says in the docs that all IO is guaranteed to occur before it returns.
A good question to ask is why this test and why arm64 only. It all points to bug(s) related to arm64 weaker memory model in the test code or in the code specifically exercised by this test.
Activity
jkotas commentedon Mar 22, 2024
This is crashing in new EH:
lewing commentedon Apr 24, 2024
@janvorli has this been fixed?
janvorli commentedon Apr 24, 2024
@lewing I believe I have looked into the original and it was actually not an issue of the new EH, but rather a regular unhandled exception or something along these lines. Unfortunately, the only two remaining failures from the list above are misclassified, so I cannot double check it now.
jkotas commentedon Apr 24, 2024
Either way, CI does not hit this anymore, so the issue can be closed.
jkotas commentedon Apr 25, 2024
Failed again in https://dev.azure.com/dnceng-public/public/_build/results?buildId=655183&view=ms.vss-test-web.build-test-results-tab&runId=16217960&resultId=100465&paneView=debug with the same stacktrace as #100114 (comment)
janvorli commentedon Apr 25, 2024
@jkotas the failure in the referenced run is just an unhandled exception. From the test log:
The last message from the actual test is
So that sounds like profiler or test related issue.
7 remaining items
jkotas commentedon Apr 26, 2024
Based on the dump, the child process exit code is 0:
It suggests that the child process exited without crashing. The problem seems to be in the parsing of the child process output.
tommcdon commentedon Apr 29, 2024
@jkotas do we expect this issue to be fixed by #101607?
jkotas commentedon Apr 29, 2024
Missing
volatilethat I have added in #101607 can explain failures with these symptoms. I suspect that my change is not going to fix the failures. The test has been failing too frequently for missingvolatileto be the root cause of the failures.I would keep this issue open for 2 weeks. If we do not see any new hits in 2 weeks, we can declare it fixed.
v-wenyuxu commentedon May 6, 2024
Failed in: runtime-coreclr r2r 20240429.1
Failed tests:
Error message:
Stack trace:
davmason commentedon May 8, 2024
The latest failure doesn't make sense to me
The profilee returned code 100 which means that the
_profilerDone.WaitOnecall succeeded, but we should only set the event after seeing all three profilers successfully detach. There are no logs indicating any profiler attached however. My only thought is that somehow we are just missing output from the profiled process, but we callProcess.WaitForExit()which says in the docs that all IO is guaranteed to occur before it returns.jkotas commentedon May 8, 2024
A good question to ask is why this test and why arm64 only. It all points to bug(s) related to arm64 weaker memory model in the test code or in the code specifically exercised by this test.
The missing
volatilethat I have added in https://github.com/dotnet/runtime/pull/101607/files#diff-667a604f90dafe4391d86c87780a736aa2eb10010f194966110baeb141d05370R198 was a bug like that. My guess is that we have more of them.davmason commentedon May 10, 2024
I fixed another issue and added a speculative fix in #102066, for now I am going to wait to see if it fails again before investigating any further
tommcdon commentedon Jun 5, 2024
There have been no issues reported by automation since this issue has been fixed, closing as "fixed"