[compiler-rt] r277558 - Reduce coverage PC buffer size on 32-bit Windows to match 32-bit Linux

Reid Kleckner via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 3 09:10:12 PDT 2016


This still isn't enough space for Chrome apparently:

C:\src\chromium\src\out\asan>chrome
[0803/085325:ERROR:file_io.cc(30)] read: expected 4, observed 0
==7920==AddressSanitizer CHECK failed:
..\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep.cc:429
"((idx * sizeof(uptr))) < ((atomic_load(&pc_array_size,
memory_order_acquire)))" (0x40256bc, 0x4000000)
    #0 0x68cd64a7 in __asan::AsanCheckFailed
c:\src\llvm\projects\compiler-rt\lib\asan\asan_rtl.cc:68
    #1 0x68cb7a43 in __sanitizer::CheckFailed
c:\src\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_termination.cc:79
    #2 0x68cb8077 in __sanitizer::CoverageData::Add
c:\src\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep.cc:428
    #3 0x68cbae54 in __sanitizer_cov
c:\src\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_coverage_libcdep.cc:947
    #4 0x57eda1f9 in _GLOBAL__sub_I_cld2_generated_quadchrome_2.cc
C:\src\chromium\src\third_party\cld_2\src\internal\cld2_generated_quadchrome_2.cc

Why do we need two of these kPcArrayMaxSize buffers? First we do this:
  pc_array = reinterpret_cast<uptr *>(
      MmapNoReserveOrDie(sizeof(uptr) * kPcArrayMaxSize, "CovInit"));

And later this:
  if (common_flags()->coverage_pc_buffer)
    pc_buffer = reinterpret_cast<uptr *>(MmapNoReserveOrDie(
        sizeof(uptr) * kPcArrayMaxSize, "CovInit::pc_buffer"));

On Tue, Aug 2, 2016 at 6:19 PM, Reid Kleckner via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Author: rnk
> Date: Tue Aug  2 20:19:46 2016
> New Revision: 277558
>
> URL: http://llvm.org/viewvc/llvm-project?rev=277558&view=rev
> Log:
> Reduce coverage PC buffer size on 32-bit Windows to match 32-bit Linux
>
> In r235779, Timur bumped the buffer size up to 1<<27, or about 134
> million coverage points, presumably to handle Chrome. We allocate two
> arrays of uptrs with this size, and this reliably exhausts all available
> address space on 32-bit Windows (2 allocations of 512MB) when ASan is
> also enabled.
>
> Let's reduce the buffer size for now to stabilize the test suite. We can
> re-evaluate the approach later when we've brought the Chrome ASan
> builders back to life.
>
> Kostya said that Mike reduced the number of instrumented coverage points
> that LLVM emits by half since Timur made this change, so reducing this
> array size should also be safe.
>
> With this change, the 32-bit ASan tests reliably pass for me on Windows
> 10.
>
> Modified:
>     compiler-rt/trunk/lib/sanitizer_common/sanitizer_coverage_libcdep.cc
>
> Modified:
> compiler-rt/trunk/lib/sanitizer_common/sanitizer_coverage_libcdep.cc
> URL:
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_coverage_libcdep.cc?rev=277558&r1=277557&r2=277558&view=diff
>
> ==============================================================================
> --- compiler-rt/trunk/lib/sanitizer_common/sanitizer_coverage_libcdep.cc
> (original)
> +++ compiler-rt/trunk/lib/sanitizer_common/sanitizer_coverage_libcdep.cc
> Tue Aug  2 20:19:46 2016
> @@ -125,9 +125,8 @@ class CoverageData {
>
>    // Maximal size pc array may ever grow.
>    // We MmapNoReserve this space to ensure that the array is contiguous.
> -  static const uptr kPcArrayMaxSize = FIRST_32_SECOND_64(
> -      1 << (SANITIZER_ANDROID ? 24 : (SANITIZER_WINDOWS ? 27 : 26)),
> -      1 << 27);
> +  static const uptr kPcArrayMaxSize =
> +      FIRST_32_SECOND_64(1 << (SANITIZER_ANDROID ? 24 : 26), 1 << 27);
>    // The amount file mapping for the pc array is grown by.
>    static const uptr kPcArrayMmapSize = 64 * 1024;
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160803/bf0b235d/attachment.html>


More information about the llvm-commits mailing list