diff options
| author | Jan Vorlicek <janvorli@microsoft.com> | 2016-06-14 01:11:09 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-06-14 01:11:09 +0200 |
| commit | a3676dd03e21501c7565c8b402a21d4f5a1428c6 (patch) | |
| tree | 11fe0e12b22bd11208171a5db9205290fe9c81a2 /tests | |
| parent | d0e2f7ebec30be026153fac8f14999e92b196df0 (diff) | |
| download | coreclr-a3676dd03e21501c7565c8b402a21d4f5a1428c6.tar.gz coreclr-a3676dd03e21501c7565c8b402a21d4f5a1428c6.tar.bz2 coreclr-a3676dd03e21501c7565c8b402a21d4f5a1428c6.zip | |
Fix PAL executable allocator locking (#5770)
We call the ExecutableAllocator from two places in PAL. One is the
VirtualAlloc when the allocation type contains MEM_RESERVE_EXECUTABLE.
The other is MAPMapPEFile.
While the former is called inside of the virtual_critsec critical section,
the latter doesn't take that critical section and so in some race cases,
we were returning the same address twice - once for VirtualAlloc and
once for MAPMapPEFile. That resulted in strange memory corruption cases.
The fix is to use the same critical section for the MAPMapPEFile too.
I am also reverting the change in the virtual commit that was made when
we have thought that the culprit might be in the mprotect.
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions