[compiler-rt] r362676 - [Profile]: Add runtime interface to specify file handle for profile data.

Wed Jun 12 01:42:38 PDT 2019

We noticed in Chromium (we're trying to start building Clang itself
with PGO) that this change is causing IR-instrumented Clang to become
crashy. (+gbiv in case he saw similar issues)

I've reverted it (and the follow-up with test cases) in r363134.

To reproduce on a Linux workstation, in the llvm monorepo checked out
at c1867557d93d622f761b57af6e66e3e518bc0b9f / r362676

$ ( mkdir build.stage1 && cd build.stage1 && cmake -GNinja
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;compiler-rt"
../llvm && ninja )
$ ( mkdir build.stage2 && cd build.stage2 &&
CC=${PWD}/../build.stage1/bin/clang
CXX=${PWD}/../build.stage1/bin/clang++ cmake -GNinja
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
-DLLVM_BUILD_INSTRUMENTED=IR ../llvm && ninja clang )
$ ( mkdir build.stage3 && cd build.stage3 &&
CC=${PWD}/../build.stage2/bin/clang
CXX=${PWD}/../build.stage2/bin/clang++ cmake -GNinja
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang ../llvm &&
ninja clang )

The instrumented Clang now crashes pretty soon, in this case:

[5/2833] Building CXX object
lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
/work/llvm.monorepo/build.stage2/bin/clang++  -DGTEST_HAS_RTTI=0
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/Support
-I/work/llvm.monorepo/llvm/lib/Support -I/usr/include/libxml2
-Iinclude -I/work/llvm.monorepo/llvm/include -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
 -fno-exceptions -fno-rtti -MD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -c
/work/llvm.monorepo/llvm/lib/Support/ConvertUTF.cpp
/work/llvm.monorepo/build.stage2/bin/clang++(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
/work/llvm.monorepo/build.stage2/bin/clang++[0x2b98c3f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7f8ad19a03a0]
/work/llvm.monorepo/build.stage2/bin/clang++[0x5817d2b]
/work/llvm.monorepo/build.stage2/bin/clang++[0x5817c42]
/work/llvm.monorepo/build.stage2/bin/clang++[0x58172e2]
/lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7f8ad04942ec]
/lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7f8ad049441a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7f8ad047e532]
/work/llvm.monorepo/build.stage2/bin/clang++(_start+0x2a)[0xa2b75a]

It's interesting to see libpthread.so on the stack. Maybe that
suggests recursive locking or something?

Trying to recompile just that file with the instrumented Clang works
fine, the crash doesn't happen every time (which is why I haven't
caught it in a debugger), but running many compilations in parallel
reproduces the issue fairly reliably:

$ cd build.stage3
$ for x in `seq 1 100` ; do ( ../build.stage2/bin/clang++
-DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support
-I../llvm/lib/Support -Iinclude -I../llvm/include -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
-fno-exceptions -fno-rtti -c ../llvm/lib/Support/ConvertUTF.cpp -o
/dev/null && echo OK ) & done

/work/llvm.monorepo/build.stage2/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
/work/llvm.monorepo/build.stage2/bin/clang-9[0x2b98c3f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7fd08f2bf3a0]
/work/llvm.monorepo/build.stage2/bin/clang-9[0x5817d2b]
/work/llvm.monorepo/build.stage2/bin/clang-9[0x5817c42]
/work/llvm.monorepo/build.stage2/bin/clang-9[0x58172e2]
/lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7fd08ddb32ec]
/lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7fd08ddb341a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7fd08dd9d532]
/work/llvm.monorepo/build.stage2/bin/clang-9(_start+0x2a)[0xa2b75a]
clang-9: error: unable to execute command: Segmentation fault
clang-9: error: clang frontend command failed due to signal (use -v to
see invocation)
clang version 9.0.0 (https://github.com/llvm/llvm-project
c1867557d93d622f761b57af6e66e3e518bc0b9f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /work/llvm.monorepo/build.stage3/../build.stage2/bin

On Thu, Jun 6, 2019 at 8:32 AM Xinliang David Li via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
>
> Author: davidxl
> Date: Wed Jun  5 23:35:18 2019
> New Revision: 362676
>
> URL: http://llvm.org/viewvc/llvm-project?rev=362676&view=rev
> Log:
> [Profile]: Add runtime interface to specify file handle for profile data.
>
> Author: Sajjad Mirza
>
> Differential Revision: http://reviews.llvm.org/D62541