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
{{ message }}
Repository navigation
Assert failure: !"Heap contamination detected! HeapFree was called on a heap other than the one that memory was allocated from.\n" #55517
If this is a consistent failure for specific test category, might make sense for the owners to investigate if there is a smaller repro and if any allocations/pinvokes are causing a corruption.
And it was in a place that's executed when we allocate a data structure from multiple threads and only one of them wins so the others free what they've allocated. That's why it was intermittent and I haven't caught it locally.
@janvorli, fyi, enabling event log with DOTNET_EnableEventLog=1 (or COMPlus_EnableEventLog=1) raises this heap contamination assertion, even with a simple 'corerun helloworld.dll'. corehost has no issue with event log.
ghost locked as resolved and limited conversation to collaborators on Sep 7, 2021
@janvorli, this assert happened in runtime-coreclr superpmi-collect pipeline, e.g., in System.Text.Json.Tests.JsonDocumentTests.CheckUnparsable(json: "[ 1") test. Could you please take a look?
This assert is a general sign of unmanaged heap corruption that can have many different root causes.
This is crashing in the superpmi tool. It is different test and scenario than this issue tracked originally. I have opened a new issue for it: #101708 .
Activity
BruceForstall commentedon Jul 12, 2021
@mangod9
mangod9 commentedon Jul 12, 2021
If this is a consistent failure for specific test category, might make sense for the owners to investigate if there is a smaller repro and if any allocations/pinvokes are causing a corruption.
mangod9 commentedon Jul 12, 2021
@karelz can some from system.net please take an initial look at the failures to determine if they might be corruption due to pinvokes here?
stephentoub commentedon Jul 13, 2021
Again here:
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-55499-merge-641ae0c0c3d241e0ac/System.Net.Requests.Tests/console.f66f1627.log?sv=2019-07-07&se=2021-08-02T02%3A22%3A55Z&sr=c&sp=rl&sig=oSYpPpupPfXa2ifp7JLYN4pM1Uk0xdYo8h%2B4xSxau90%3D
mangod9 commentedon Jul 13, 2021
Adding @janvorli as well in case this is related to the w^x work, assuming this started happening in the past day or so.
janvorli commentedon Jul 13, 2021
I've found the issue, I'll create a PR with a fix in a minute.
karelz commentedon Jul 13, 2021
Thanks @janvorli! Out of curiosity, what caused the problems? Was it w^x work or some churn in Networking/crypto?
janvorli commentedon Jul 13, 2021
W^X work, I've forgotten to replace one call to c++ delete by an appropriate executable heap method.
janvorli commentedon Jul 13, 2021
And it was in a place that's executed when we allocate a data structure from multiple threads and only one of them wins so the others free what they've allocated. That's why it was intermittent and I haven't caught it locally.
am11 commentedon Aug 5, 2021
@janvorli, fyi, enabling event log with
DOTNET_EnableEventLog=1(orCOMPlus_EnableEventLog=1) raises this heap contamination assertion, even with a simple 'corerun helloworld.dll'. corehost has no issue with event log.JulieLeeMSFT commentedon Apr 29, 2024
@janvorli, this assert happened in runtime-coreclr superpmi-collect pipeline, e.g., in System.Text.Json.Tests.JsonDocumentTests.CheckUnparsable(json: "[ 1") test. Could you please take a look?
jkotas commentedon Apr 30, 2024
This assert is a general sign of unmanaged heap corruption that can have many different root causes.
This is crashing in the superpmi tool. It is different test and scenario than this issue tracked originally. I have opened a new issue for it: #101708 .