[llvm-dev] PassManager test failing on AArch64

David A. Greene via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 11 13:36:03 PDT 2018 

I verified that the failure goes away when built in Debug mode or when
built with gcc 8.2.0 in Release mode.

When built in Debug mode with gcc 6.1.0 valgrind reports no problems for
PassManagerTest.IndirectAnalysisInvalidation but does report many more
problems similar to the one for ConstantsTest.ReplaceWithConstantTest.

                          -David

David Greene via llvm-dev <llvm-dev at lists.llvm.org> writes:

> With LLVM built using gcc 6.1.0 in Release mode on AArch64, I see a unit
> test failure:
>
> ********************
> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
> Testing Time: 4.86s
> ********************
> Failing Tests (1):
>     LLVM-Unit :: IR/./IRTests/PassManagerTest.IndirectAnalysisInvalidation
>
> This seems to go away when compiled with gcc 8.2.0.  I have not yet
> tried a Debug build.  The failure mode makes me concerned about
> undefined behavior in either the PassManager or the test.  I am not
> familiar enough with the new PassManager stuff to really dive into this
> without some direction/help.
>
> valgrind reports this when running IRTests:
>
> [ RUN      ] PassManagerTest.IndirectAnalysisInvalidation
> Starting llvm::Module pass manager run.
> Running pass: RequireAnalysisPass<{anonymous}::TestModuleAnalysis, llvm::Module> on <string>
> Running analysis: {anonymous}::TestModuleAnalysis on <string>
> Running pass: ModuleToFunctionPassAdaptor<llvm::PassManager<llvm::Function> > on <string>
> Running analysis: InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Function>, llvm::Module> on <string>
> Starting llvm::Function pass manager run.
> Running pass: {anonymous}::LambdaPass on f
> Running analysis: {anonymous}::TestDoublyIndirectFunctionAnalysis on f
> Running analysis: {anonymous}::TestIndirectFunctionAnalysis on f
> Running analysis: {anonymous}::TestFunctionAnalysis on f
> Running analysis: OuterAnalysisManagerProxy<llvm::AnalysisManager<llvm::Module>, llvm::Function> on f
> ==68041== Use of uninitialised value of size 8
> ==68041==    at 0x6123C8: std::_Function_handler<llvm::PreservedAnalyses (llvm::Function&, llvm::AnalysisManager<llvm::Function>&), (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody()::{lambda(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)#7}>::_M_invoke(std::_Any_data const&, llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x609BEB: llvm::detail::PassModel<llvm::Function, (anonymous namespace)::LambdaPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x611D5F: llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor<llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x910B97: llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x615C23: (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CAB3: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CCBB: testing::Test::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D847: testing::TestInfo::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D913: testing::TestCase::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1FE27: testing::internal::UnitTestImpl::RunAllTests() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA20183: testing::UnitTest::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x485F53: main (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041== 
> ==68041== Invalid read of size 4
> ==68041==    at 0x6123C8: std::_Function_handler<llvm::PreservedAnalyses (llvm::Function&, llvm::AnalysisManager<llvm::Function>&), (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody()::{lambda(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)#7}>::_M_invoke(std::_Any_data const&, llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x609BEB: llvm::detail::PassModel<llvm::Function, (anonymous namespace)::LambdaPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x611D5F: llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor<llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x910B97: llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x615C23: (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CAB3: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CCBB: testing::Test::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D847: testing::TestInfo::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D913: testing::TestCase::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1FE27: testing::internal::UnitTestImpl::RunAllTests() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA20183: testing::UnitTest::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x485F53: main (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==68041== 
> ==68041== Conditional jump or move depends on uninitialised value(s)
> ==68041==    at 0x4BCCC20: uw_frame_state_for (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68041==    by 0x4BCE43F: _Unwind_Backtrace (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68041==    by 0x4CC7E7F: backtrace (in /lib64/libc-2.22.so)
> ==68041==    by 0x9A31DF: llvm::sys::PrintStackTrace(llvm::raw_ostream&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x9A18E7: llvm::sys::RunSignalHandlers() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x9A1A3F: SignalHandler(int) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x580572DF: ??? (in /cray/css/compiler/cost/compiler_tools/installs/valgrind/3.13.0/SUSE/12.2/aarch64/install/lib/valgrind/memcheck-arm64-linux)
> ==68041== 
> /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests[0x9a31df]
> /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests[0x9a18e7]
> /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests[0x9a1a3f]
> [0x580572df]
> /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests[0x6123a7]
> [0x5884657]
> ==68041== 
> ==68041== Process terminating with default action of signal 11 (SIGSEGV)
> ==68041==  Access not within mapped region at address 0x0
> ==68041==    at 0x6123C8: std::_Function_handler<llvm::PreservedAnalyses (llvm::Function&, llvm::AnalysisManager<llvm::Function>&), (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody()::{lambda(llvm::Function&, llvm::AnalysisManager<llvm::Function>&)#7}>::_M_invoke(std::_Any_data const&, llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x609BEB: llvm::detail::PassModel<llvm::Function, (anonymous namespace)::LambdaPass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x611D5F: llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor<llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x910B97: llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x615C23: (anonymous namespace)::PassManagerTest_IndirectAnalysisInvalidation_Test::TestBody() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CAB3: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1CCBB: testing::Test::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D847: testing::TestInfo::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1D913: testing::TestCase::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA1FE27: testing::internal::UnitTestImpl::RunAllTests() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0xA20183: testing::UnitTest::Run() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==    by 0x485F53: main (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68041==  If you believe this happened as a result of a stack
> ==68041==  overflow in your program's main thread (unlikely but
> ==68041==  possible), you can try to increase the size of the
> ==68041==  main thread stack using the --main-stacksize= flag.
> ==68041==  The main thread stack size used in this run was 8388608.
> ==68041== 
> ==68041== HEAP SUMMARY:
> ==68041==     in use at exit: 310,869 bytes in 2,317 blocks
> ==68041==   total heap usage: 67,953 allocs, 65,636 frees, 30,301,473 bytes allocated
> ==68041== 
> ==68041== LEAK SUMMARY:
> ==68041==    definitely lost: 70,656 bytes in 1 blocks
> ==68041==    indirectly lost: 0 bytes in 0 blocks
> ==68041==      possibly lost: 1,196 bytes in 14 blocks
> ==68041==    still reachable: 239,017 bytes in 2,302 blocks
> ==68041==         suppressed: 0 bytes in 0 blocks
> ==68041== Rerun with --leak-check=full to see details of leaked memory
> ==68041== 
> ==68041== For counts of detected and suppressed errors, rerun with: -v
> ==68041== Use --track-origins=yes to see where uninitialised values come from
> ==68041== ERROR SUMMARY: 5 errors from 3 contexts (suppressed: 0 from 0)
>
> valgrind also reports this, but I think it is unrelated.  I'm not sure
> valgrind knows how to handle EXPECT_DEATH tests.
>
> [ RUN      ] ConstantsTest.ReplaceWithConstantTest
> ==68043== Invalid read of size 8
> ==68043==    at 0x4BCDC28: uw_update_context (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68043==    by 0x4BCE433: _Unwind_Backtrace (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68043==    by 0x4CC7E7F: backtrace (in /lib64/libc-2.22.so)
> ==68043==    by 0x9A31DF: llvm::sys::PrintStackTrace(llvm::raw_ostream&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x9A18E7: llvm::sys::RunSignalHandlers() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x9A1A3F: SignalHandler(int) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x580572DF: ??? (in /cray/css/compiler/cost/compiler_tools/installs/valgrind/3.13.0/SUSE/12.2/aarch64/install/lib/valgrind/memcheck-arm64-linux)
> ==68043==  Address 0xf is not stack'd, malloc'd or (recently) free'd
> ==68043== 
> ==68043== 
> ==68043== Process terminating with default action of signal 11 (SIGSEGV)
> ==68043==  Access not within mapped region at address 0xF
> ==68043==    at 0x4BCDC28: uw_update_context (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68043==    by 0x4BCE433: _Unwind_Backtrace (in /opt/gcc/6.1.0/snos/lib64/libgcc_s.so.1)
> ==68043==    by 0x4CC7E7F: backtrace (in /lib64/libc-2.22.so)
> ==68043==    by 0x9A31DF: llvm::sys::PrintStackTrace(llvm::raw_ostream&) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x9A18E7: llvm::sys::RunSignalHandlers() (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x9A1A3F: SignalHandler(int) (in /ptmp/dag/clang-build/cce-clang/master/release/cce-clang/aarch64/unittests/IR/IRTests)
> ==68043==    by 0x580572DF: ??? (in /cray/css/compiler/cost/compiler_tools/installs/valgrind/3.13.0/SUSE/12.2/aarch64/install/lib/valgrind/memcheck-arm64-linux)
> ==68043==  If you believe this happened as a result of a stack
> ==68043==  overflow in your program's main thread (unlikely but
> ==68043==  possible), you can try to increase the size of the
> ==68043==  main thread stack using the --main-stacksize= flag.
> ==68043==  The main thread stack size used in this run was 8388608.
> ==68043== 
> ==68043== HEAP SUMMARY:
> ==68043==     in use at exit: 309,335 bytes in 2,402 blocks
> ==68043==   total heap usage: 8,090 allocs, 5,688 frees, 5,180,714 bytes allocated
> ==68043== 
> ==68043== LEAK SUMMARY:
> ==68043==    definitely lost: 70,656 bytes in 1 blocks
> ==68043==    indirectly lost: 0 bytes in 0 blocks
> ==68043==      possibly lost: 200 bytes in 2 blocks
> ==68043==    still reachable: 238,479 bytes in 2,399 blocks
> ==68043==         suppressed: 0 bytes in 0 blocks
> ==68043== Rerun with --leak-check=full to see details of leaked memory
> ==68043== 
> ==68043== For counts of detected and suppressed errors, rerun with: -v
> ==68043== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>
> I am happy to keep investigating but I will need some suggestions.  Is
> it convenient/possible to build unit tests with ubsan and friends?
>
>                         -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list