[compiler-rt] r263160 - [Windows] Fix UnmapOrDie and MmapAlignedOrDie

[Dmitry Vyukov via llvm-commits]

On Wed, Apr 27, 2016 at 6:39 PM, Dmitry Vyukov <dvyukov at google.com> wrote:
> On Wed, Apr 27, 2016 at 6:35 PM, Reid Kleckner <rnk at google.com> wrote:
>> On Wed, Apr 27, 2016 at 9:26 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
>>>
>>> Hi,
>>>
>>> I had to restore the MEM_DECOMMIT part (r267730). Tsan relies on the
>>> old behavior.
>>> We can think of a better fix, but I needed to contain fire and update
>>> Go runtimes because commit window closes in few days and I will OOO
>>> the remaining days. So a delay here would mean 6 month delay in
>>> deployment of important fixes for Go.
>>
>>
>> I was not aware that we supported TSan on Windows. Does it have tests?
>>
>> In the long term, TSan should not attempt to partially unmap a region.
>> Windows doesn't appear to support that. With your change, TSan on Windows
>> will essentially leak address space. I would really like to get back the
>> CHECK ASAP so that ASan doesn't accidentally end up with any similar leaks.
>
> Tsan unmaps only once per thread descriptor, so it does not leak
> continuously. The address is aligned on 64k. It works.
>
> If the address/size that asan passes to Unmap are not always aligned
> on 64k, then it will be caught as failed VirtualFree(MEM_DECOMMIT), so
> asan won't regress.


Reid,

How do you think we should fix it?