This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Fix sanitizer memory allocator on win64.
ClosedPublic

Authored by etienneb on Jun 30 2016, 11:24 AM.

Details

Summary

This patch is fixing unittests for sanitizer memory allocator.

There was two issues:

  1. The VirtualAlloc can't reserve twice a memory range. The memory space used by the SizeClass allocator is reserved with NoAccess and pages are commited on demand (using MmapFixedOrDie).
  2. The address space is allocated using two VirtualAlloc calls. The first one for the memory space, the second one for the AdditionnalSpace (after).

    On windows, they need to be freed separately.

Diff Detail

Event Timeline

etienneb updated this revision to Diff 62387.Jun 30 2016, 11:24 AM
etienneb retitled this revision from to [compiler-rt] Fix sanitizer memory allocator on win64..
etienneb updated this object.
etienneb added a reviewer: rnk.

chrisha@ prosposed that we implement an other flavor of MMap to remap memory previously created with NoAccess.

Any toughs?

etienneb updated this object.Jun 30 2016, 11:28 AM
rnk added inline comments.Jun 30 2016, 11:42 AM
lib/sanitizer_common/sanitizer_win.cc
187

Which is more common, committing previously reserved memory or reserve+committing a large chunk of memory? We should do the common one first.

Also, this needs a comment that VirtualAlloc with MEM_RESERVE will fail if the memory was previously reserved, and in that case we should only pass MEM_COMMIT.

204

Uh, yeah, committing memory with no access seems like the wrong behavior...

lib/sanitizer_common/tests/sanitizer_allocator_test.cc
39–41

Should these changes be under #if SANITIZER_WINDOWS so that we test the full address space range on Linux?

rnk edited edge metadata.Jun 30 2016, 11:42 AM

chrisha@ prosposed that we implement an other flavor of MMap to remap memory previously created with NoAccess.

I like this better. I think if we try to hard to pretend we have mmap we will eventually go crazy.

I'll move forward with adding a new flavor of mmap.
I can't tell how hard that will be. :)

lib/sanitizer_common/tests/sanitizer_allocator_test.cc
39–41

I should take a deeper look to the range that Windows can accept.

In D21900#471571, @rnk wrote:

chrisha@ prosposed that we implement an other flavor of MMap to remap memory previously created with NoAccess.

I like this better. I think if we try to hard to pretend we have mmap we will eventually go crazy.

I think we should really build a table of the various memory concepts on Posix/Windows, and how they map to each other. And then build an abstract set of memory management functions that provides clean concepts across platforms.

(Without sitting down and trying it, I'm not sure that's possible or desirable in the long run.)

etienneb updated this revision to Diff 62932.Jul 6 2016, 12:25 PM
etienneb marked 4 inline comments as done.
etienneb edited edge metadata.

fix

rnk accepted this revision.Jul 7 2016, 10:07 AM
rnk edited edge metadata.

lgtm

This revision is now accepted and ready to land.Jul 7 2016, 10:07 AM
etienneb closed this revision.Jul 7 2016, 10:51 AM