Make GC stress usable with Libraries tests #103738
Conversation
VSadov
added
test-enhancement
|
Tagging subscribers to this area: @mangod9 |
VSadov
force-pushed
the
gcstress01
branch
2 times, most recently
from
71b0141
to
a05d762
Compare
|
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
|
Azure Pipelines successfully started running 2 pipeline(s). |
| // Under GC stress the finalizer queue may never go empty as frequent | ||
| // GCs will keep filling up the queue with items. | ||
| // We will disable GC stress to make sure the current thread is not permanently blocked on that. | ||
| GCStressPolicy::InhibitHolder iholder; |
There was a problem hiding this comment.
InhibitHolder increments global counter without using Interlocked. We may want to fix to avoid race conditions that can make this inhibit holder ineffective intermittently and cause hangs.
There was a problem hiding this comment.
I did not realize that. This is dangerous and may be already causing some rare failures in stress.
Co-authored-by: Jan Kotas <[email protected]>
| //---------------------------------------------------- | ||
|
|
||
| DWORD status = hEventFinalizerDone->Wait(INFINITE,TRUE); | ||
| _ASSERTE(status == WAIT_OBJECT_0); |
There was a problem hiding this comment.
This place does not complain about unused local.
There was a problem hiding this comment.
I am not sure I have seen before that this can break the build.
There was a problem hiding this comment.
Maybe the other case is included somewhere that is built with more strict rules.
There was a problem hiding this comment.
My guess is that this does not complain because DWORD is typedef, so it is a potentially complex type where the local variable may be impactful ... until some compiler decides to warn for this case too.
I would not hurt to change this one to the make-compiler-happy pattern.
There was a problem hiding this comment.
We may have quite a few of these. Fixed this one.
|
Thanks!!! |
Fixes: #101150
Also useful to investigate failures like: #102919