-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Test failure Loader\\classloader\\DictionaryExpansion\\DictionaryExpansion\\DictionaryExpansion.cmd #75244
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Failed again in: runtime-coreclr outerloop 20221018.4 Failed test:
Error message:
|
Failed again in: runtime-coreclr jitstressregs 20221225.1 Failed test:
Error message:
|
Failed again in: runtime-coreclr outerloop 20230102.2 Failed test:
Error message:
|
Failed again in https://github.com/dotnet/runtime/pull/78544/checks?check_run_id=10921602265
|
I have reassigned the bug to myself as David is expected to be OOF for a prolonged period of time. I'm now working with @janvorli on the initial pointers, as it's apparently x86-specific my first guess is that it's probably related to architecture-specific rules for emitting stubs. |
Failed again in: runtime-coreclr outerloop 20230205.2 Failed test:
Error message:
|
Failed again in: runtime-coreclr jitstress-isas-x86 20230211.1 Failed tests:
Error message:
Stack trace:
|
I kept trying to repro the issue locally, but so far, I was unable to succeed. I've ran the test in a loop for two days and there was no repro. |
When a RX mapping in the ExecutableAllocation is released and there is a RW mapping cached for it, it incorrectly stays in the cache. So when the same virtual address range that was just released gets reserved again and a request to get RW mapping comes in, the cached RW mapping is used. But it is likely that the new RX mapping has a different offset in the underlying file mapping and thus the RW mapping is unrelated to the new RX mapping. Using this RW mapping results either in an overwrite of a different block of memory or just a silent dropping of what's written. This was discovered when investigating a GC reliability framework crash. It turned out it was also the culprit behind the dotnet#75244 issue that I was unable to reproduce and it kept occuring in the CI on x86 only for quite some time. In addition to the fix, I've found that there was an off by one condition in the ExecutableAllocator::FindRWBlock so I've fixed that. And I've also noticed that in UnlockedLoaderHeap::UnlockedReservePages, if the allocation of LoaderHeapBlock failed, we would leave the data block incorrectly on the m_pRangeList. I've fixed that too. Close dotnet#75244
…82841) When a RX mapping in the ExecutableAllocation is released and there is a RW mapping cached for it, it incorrectly stays in the cache. So when the same virtual address range that was just released gets reserved again and a request to get RW mapping comes in, the cached RW mapping is used. But it is likely that the new RX mapping has a different offset in the underlying file mapping and thus the RW mapping is unrelated to the new RX mapping. Using this RW mapping results either in an overwrite of a different block of memory or just a silent dropping of what's written. This was discovered when investigating a GC reliability framework crash. It turned out it was also the culprit behind the #75244 issue that I was unable to reproduce and it kept occuring in the CI on x86 only for quite some time. In addition to the fix, I've found that there was an off by one condition in the ExecutableAllocator::FindRWBlock so I've fixed that. And I've also noticed that in UnlockedLoaderHeap::UnlockedReservePages, if the allocation of LoaderHeapBlock failed, we would leave the data block incorrectly on the m_pRangeList. I've fixed that too. Close #75244
Run: runtime-coreclr outerloop 20220907.7
Failed test:
Error Message
Fill the error message using known issues guidance.
Report
Summary
The text was updated successfully, but these errors were encountered: