[compiler-rt] r263160 - [Windows] Fix UnmapOrDie and MmapAlignedOrDie
Dmitry Vyukov via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 27 09:39:55 PDT 2016
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.
More information about the llvm-commits
mailing list