-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
commenting out an assert that could be triggered on Win7 #57524
Conversation
Tagging subscribers to this area: @dotnet/gc Issue DetailsFixes:#57137 This is just a sanity assert to make sure we use the
|
Thanks!! |
Hello @VSadov! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
_ASSERTE(!success && GetLastError() == ERROR_INSUFFICIENT_BUFFER); | ||
// The following assert is valid, but gets triggered in some Win7 runs with no impact on functionality. | ||
// commenting this out to reduce noise, as long as Win7 is supported. | ||
// _ASSERTE(!success && GetLastError() == ERROR_INSUFFICIENT_BUFFER); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we know what condition fails on win7. Assume that the error returned is not ERROR_INSUFFICIENT_BUFFER
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it cannot succeed with NULL
buffer, so most likely it is a different or lost error code.
I do not have Win7 available and as I understand it does not always cause the assert. It is curious, but could be time consuming to find out.
In any case, if this API is not telling us the desired size of the buffer it would be a situation that we cannot handle and it would be fatal in the next call to this API anyways. It would also indicate that something went really wrong on the OS side.
I do not think the value of this assert is very high. I think we use the API correctly and with the comments around it is unlikely to accidentally regress.
The OSX changes are a Helix infra issue. The Windows x86 test failure is also intermittently failing in main. @VSadov I think we can merge this if you want to. |
@jkoritzinsky - Thanks! I prefer PRs to merge green, but I do not see how these failures are even remotely related to removal of an assert. I will merge this. |
Fixes:#57137
This is just a sanity assert to make sure we use the
InitializeContext
API correctly, which we do.However the assert seems to be triggered in some Win7 runs with no impact on actual functionality. The easiest way to deal with that is just to disable the assert.