-
Notifications
You must be signed in to change notification settings - Fork 1k
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
WebBrowser doesn't like multiple UI threads #3473
Conversation
@RussKie somehow I missed "hidden" usages of WebBrowser (AxHost instantiated via WebBrowser GUID), its not worth to look at any dumps until this is merged or crashes in the CI of this PR, since without this fix you won't be able to easily differentiate WebBrowser corruption from potential other corruption. Lets hope we were just observing more WebBrowser corruption and there is no second source. 🙏 |
Failed test |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
linking failed test run if inspection is desired
|
Codecov Report
@@ Coverage Diff @@
## master #3473 +/- ##
====================================================
+ Coverage 66.75048% 98.50616% +31.75567%
====================================================
Files 1340 446 -894
Lines 503081 249692 -253389
Branches 40834 4091 -36743
====================================================
- Hits 335809 245962 -89847
+ Misses 161711 3019 -158692
+ Partials 5561 711 -4850
|
Took a look at the crash dump, its heap corruption, that means I either missed a test invoking WebBrowser COM objects or there is a second source of corruption. Can't tell much more at the moment, dumps still unreadable. |
Workaround for #3358
(Extended version of PR #3423 and #3429)
Like mentioned on the other PR this is only a workaround and not a final solution, further investigation to the memory corruption issues are desired. There is also the possibility of another memory corruption source we did not pinpoint yet.
Proposed changes
Prevent running WebBrowser control tests on multiple UI threads in parallel as that seems to cause memory corruption (unknown whether root cause is in WinForms or native control)
Customer Impact
no random crashes due to memory corruption in unit tests, should improve CI sucess rates
Regression?
no
Risk
may slow down tests a bit
Before
random CI crashes or test failures that made no sense due to memory corruption
After
prevent memory corruption, allowing CI runs to perform normally
Test methodology
isolated repro scenario into a separate application, it doesn't seem to cause memory corruption when only one UI thread is running the WebBrowser control
Microsoft Reviewers: Open in CodeFlow