<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss <<a href="mailto:friss@apple.com">friss@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jan 4, 2019, at 7:30 AM, Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
> <br>
> On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss <<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>> wrote:<br>
> -llvm-dev + lldb-dev for the lldv test failures.<br>
> <br>
>> On Jan 3, 2019, at 7:33 AM, Joel E. Denny <<a href="mailto:jdenny.ornl@gmail.com" target="_blank">jdenny.ornl@gmail.com</a>> wrote:<br>
>> <br>
>> All,<br>
>> <br>
>> Thanks for the replies. Kuba: For LLDB, when were things expected to have improved? It's possible things improved for me at some point, but this isn't something I've found time to track carefully, and I still see problems. <br>
>> <br>
>> I ran check-all a couple of times last night at r350238, which I pulled yesterday. Here are the results:<br>
>> <br>
>> ```<br>
>> ********************<br>
>> Testing Time: 5043.24s<br>
>> ********************<br>
>> Unexpected Passing Tests (2):<br>
>> lldb-Suite :: functionalities/asan/TestMemoryHistory.py<br>
>> lldb-Suite :: functionalities/asan/TestReportData.py<br>
>> <br>
>> ********************<br>
>> Failing Tests (54):<br>
>> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp<br>
>> Clang :: Modules/ExtDebugInfo.cpp<br>
>> Clang :: Modules/using-directive-redecl.cpp<br>
>> Clang :: Modules/using-directive.cpp<br>
>> Clang :: PCH/chain-late-anonymous-namespace.cpp<br>
>> Clang :: PCH/cxx-namespaces.cpp<br>
>> Clang :: PCH/namespaces.cpp<br>
>> LLDB :: ExecControl/StopHook/stop-hook-threads.test<br>
>> LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc<br>
>> LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc<br>
>> MemorySanitizer-X86_64 :: dtls_test.c<br>
>> MemorySanitizer-lld-X86_64 :: dtls_test.c<br>
>> lldb-Suite :: functionalities/register/register_command/TestRegisters.py<br>
>> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py<br>
> <br>
> It’s hard to diagnose dotest failures without the log. <br>
> <br>
> (My last reply to this was rejected by the list because I wasn't subscribed. Trying again.)<br>
> <br>
> I have no experience debugging lldb. Here's the lit output for the last fail (now at r350377), but let me know if you want something more:<br>
> <br>
> ```<br>
> FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py (59083 of 59736)<br>
> ******************** TEST 'lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED ********************<br>
> lldb version 8.0.0<br>
> LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin<br>
> LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin<br>
> Libc++ tests will not be run because: Unable to find libc++ installation<br>
> Skipping following debug info categories: ['dsym', 'gmodules']<br>
> <br>
> Session logs for test failures/errors/unexpected successes will go into directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces'<br>
> Command invoked: /home/jdenny/ornl/llvm-mono-git/lldb/test/dotest.py -q --arch=x86_64 -s /home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces --build-dir /home/jdenny/ornl/llvm-mono-git-build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/jdenny/ornl/llvm-mono-git-build/./bin/lldb --dsymutil /home/jdenny/ornl/llvm-mono-git-build/./bin/dsymutil --filecheck /home/jdenny/ornl/llvm-mono-git-build/./bin/FileCheck -C /home/jdenny/ornl/llvm-mono-git-build/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy /home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server -p TestGdbRemoteRegisterState.py<br>
> UNSUPPORTED: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: test_grp_register_save_restore_works_no_suffix_debugserver (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) <br>
> FAIL: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: test_grp_register_save_restore_works_no_suffix_llgs (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)<br>
> lldb-server exiting...<br>
> UNSUPPORTED: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: test_grp_register_save_restore_works_with_suffix_debugserver (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) <br>
> FAIL: LLDB (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: test_grp_register_save_restore_works_with_suffix_llgs (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)<br>
> lldb-server exiting...<br>
> ======================================================================<br>
> FAIL: test_grp_register_save_restore_works_no_suffix_llgs (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)<br>
> ----------------------------------------------------------------------<br>
> Traceback (most recent call last):<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", line 144, in wrapper<br>
> func(*args, **kwargs)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", line 137, in test_grp_register_save_restore_works_no_suffix_llgs<br>
> self.grp_register_save_restore_works(USE_THREAD_SUFFIX)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", line 97, in grp_register_save_restore_works<br>
> context = self.expect_gdbremote_sequence()<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 713, in expect_gdbremote_sequence<br>
> self.logger)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 261, in expect_lldb_gdbserver_replay<br>
> asserter, content, context=context)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 564, in assert_match<br>
> self._assert_exact_payload_match(asserter, actual_packet)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 518, in _assert_exact_payload_match<br>
> assert_packets_equal(asserter, actual_packet, self.exact_payload)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 159, in assert_packets_equal<br>
> asserter.assertEqual(actual_stripped, expected_stripped)<br>
> AssertionError: '$E77' != '$OK'<br>
> Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8<br>
> ======================================================================<br>
> FAIL: test_grp_register_save_restore_works_with_suffix_llgs (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)<br>
> ----------------------------------------------------------------------<br>
> Traceback (most recent call last):<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", line 144, in wrapper<br>
> func(*args, **kwargs)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", line 121, in test_grp_register_save_restore_works_with_suffix_llgs<br>
> self.grp_register_save_restore_works(USE_THREAD_SUFFIX)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", line 97, in grp_register_save_restore_works<br>
> context = self.expect_gdbremote_sequence()<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 713, in expect_gdbremote_sequence<br>
> self.logger)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 261, in expect_lldb_gdbserver_replay<br>
> asserter, content, context=context)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 564, in assert_match<br>
> self._assert_exact_payload_match(asserter, actual_packet)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 518, in _assert_exact_payload_match<br>
> assert_packets_equal(asserter, actual_packet, self.exact_payload)<br>
> File "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", line 159, in assert_packets_equal<br>
> asserter.assertEqual(actual_stripped, expected_stripped)<br>
> AssertionError: '$E77' != '$OK'<br>
> Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8<br>
> ----------------------------------------------------------------------<br>
> Ran 4 tests in 22.052s<br>
<br>
I’m not familiar with the lldb-server tests. Pavel might know what Error 77 is?<br>
<br>
> RESULT: FAILED (0 passes, 2 failures, 0 errors, 2 skipped, 0 expected failures, 0 unexpected successes)<br>
> <br>
> ********************<br>
> ```<br>
> <br>
> <br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestDictionaryResolutionWithDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestExtractingUInt64ThroughStructuredData<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionNoDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionWithDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestInstanceNameResolutionNoDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestModuleNameResolutionNoDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestObjectAttributes<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestOwnedReferences<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonByteArray<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonBytes<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableCheck<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableInvoke<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryManipulation<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryToStructuredDictionary<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryValueEquality<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonFile<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonInteger<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStr<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStructuredInteger<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListManipulation<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListToStructuredList<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListValueEquality<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonString<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStr<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStructuredString<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList2<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleSize<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleToStructuredList<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleValues<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestResetting<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestTypeNameResolutionNoDot<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAcquisitionSemantics<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreChanged<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreSemantics<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestDiscardSemantics<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestExceptionStateChecking<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestManualRestoreSemantics<br>
>> lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics<br>
> <br>
> Those unit test failures don’t ring a bell. Anyone’s seen this? Here too, knowing exactly the error message would help.<br>
> <br>
> Here's the lit output for the last one:<br>
> <br>
> ```<br>
> FAIL: lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics (59324 of 59736)<br>
> ******************** TEST 'lldb-Unit :: ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics' FAILED ********************<br>
> Note: Google Test filter = PythonExceptionStateTest.TestResetSemantics<br>
> [==========] Running 1 test from 1 test case.<br>
> [----------] Global test environment set-up.<br>
> [----------] 1 test from PythonExceptionStateTest<br>
> [ RUN ] PythonExceptionStateTest.TestResetSemantics<br>
> ScriptInterpreterPythonTests: /home/jdenny/ornl/llvm-mono-git/llvm/include/llvm/Support/CommandLine.h:800: void llvm::cl::parser<llvm::ScheduleDAGInstrs *(*)(llvm::MachineSchedContext *)>::addLiteralOption(llvm::StringRef, const DT &, llvm::StringRef) [DataType = llvm::ScheduleDAGInstrs *(*)(llvm::MachineSchedContext *), DT = llvm::ScheduleDAGInstrs *(*)(llvm::MachineSchedContext *)]: Assertion `findOption(Name) == Values.size() && "Option already exists!"' failed.<br>
<br>
That’s interesting. It seems like some clots are registered twice. As he backtrace shows that you have a libLLVMSupport.so, I could imagine this happening if the unittest was linking with both a static version and the dynamic version of the LLVM libraries, but that’s just a theory. I don’t know how good the build system is at dealing with a libraries build of LLVM, I wouldn’t be surprised if this is untested and thus broken.<br></blockquote><div><br></div><div>I rebuilt without -DBUILD_SHARED_LIBS=true, and all the previous failing clang and lldb-Unit tests then passed (other test results did not change). My build size jumped from 33G to 136G. I didn't pay attention to the build time this time, but my past experience is that incremental builds can be many times slower without -DBUILD_SHARED_LIBS=true. This does not seem like a good solution for me.</div><div><br></div><div>Joel<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Fred <br>
<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x39)[0x7fc0daf41b29]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(+0x32ecd9)[0x7fc0daf41cd9]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(_ZN4llvm3sys17RunSignalHandlersEv+0x76)[0x7fc0daf3fd86]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(+0x32f37b)[0x7fc0daf4237b]<br>
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fc0e2a48890]<br>
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fc0d7589e97]<br>
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fc0d758b801]<br>
> /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7fc0d757b39a]<br>
> /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7fc0d757b412]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMCodeGen.so.8svn(+0x5d7f5e)[0x7fc0cffcbf5e]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMCodeGen.so.8svn(+0x5d7a07)[0x7fc0cffcba07]<br>
> /usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1(+0x6db7a1)[0x7fc0c8c2d7a1]<br>
> /lib64/ld-linux-x86-64.so.2(+0x10733)[0x7fc0e2c65733]<br>
> /lib64/ld-linux-x86-64.so.2(+0x151ff)[0x7fc0e2c6a1ff]<br>
> /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_exception+0x6f)[0x7fc0d76b22df]<br>
> /lib64/ld-linux-x86-64.so.2(+0x147ca)[0x7fc0e2c697ca]<br>
> /lib/x86_64-linux-gnu/libdl.so.2(+0xf96)[0x7fc0daa0ff96]<br>
> /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_exception+0x6f)[0x7fc0d76b22df]<br>
> /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_error+0x2f)[0x7fc0d76b236f]<br>
> /lib/x86_64-linux-gnu/libdl.so.2(+0x1735)[0x7fc0daa10735]<br>
> /lib/x86_64-linux-gnu/libdl.so.2(dlopen+0x71)[0x7fc0daa10051]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(_PyImport_GetDynLoadFunc+0x120)[0x7fc0e21dd4f0]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(_PyImport_LoadDynamicModule+0x70)[0x7fc0e2167c80]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4afe)[0x7fc0e21ebafe]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x151e91)[0x7fc0e2168e91]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x152176)[0x7fc0e2169176]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x2f5)[0x7fc0e2169565]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0xb4de4)[0x7fc0e20cbde4]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fc0e206b333]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fc0e21f57a7]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3909)[0x7fc0e20c1ac9]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc0e21f6278]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc0e20be029]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0xac)[0x7fc0e21e61cc]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4462)[0x7fc0e21eb462]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4a3e)[0x7fc0e21eba3e]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4d4a)[0x7fc0e21ebd4a]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x151e91)[0x7fc0e2168e91]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x122)[0x7fc0e2169392]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0xb4de4)[0x7fc0e20cbde4]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fc0e206b333]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fc0e21f57a7]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3909)[0x7fc0e20c1ac9]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc0e21f6278]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc0e20be029]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fc0e2161546]<br>
> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_SimpleStringFlags+0x3b)[0x7fc0e21615db]<br>
> /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x4d3cd2]<br>
> /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x4863c8]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x7e)[0x7fc0e25f482e]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x72)[0x7fc0e25dfa22]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing4Test3RunEv+0x74)[0x7fc0e25cd004]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8TestInfo3RunEv+0xe3)[0x7fc0e25cd913]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8TestCase3RunEv+0xec)[0x7fc0e25cde6c]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x2e1)[0x7fc0e25d35b1]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc+0x7e)[0x7fc0e25f801e]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc+0x72)[0x7fc0e25e17c2]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8UnitTest3RunEv+0xc2)[0x7fc0e25d32a2]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest_main.so.8svn(+0xbe1)[0x7fc0e2834be1]<br>
> /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest_main.so.8svn(main+0x148)[0x7fc0e2834bb8]<br>
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fc0d756cb97]<br>
> /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x47196a]<br>
> ```<br>
> <br>
> Joel<br>
> <br>
> <br>
>> Expected Passes : 57489<br>
>> Expected Failures : 276<br>
>> Unsupported Tests : 1883<br>
>> Unexpected Passes : 2<br>
>> Unexpected Failures: 54<br>
>> <br>
>> 14 warning(s) in tests.<br>
>> FAILED: CMakeFiles/check-all<br>
>> ```<br>
>> <br>
>> I immediately ran it again and saw one new unexpected fail:<br>
>> <br>
>> ```<br>
>> lldb-Suite :: tools/lldb-mi/syntax/TestMiSyntax.py<br>
>> ```<br>
> <br>
> Adrian, do we have remaining flakiness in the MI tests? Is this one of the GSoc tests?<br>
> <br>
>> and one new unresolved test:<br>
>> <br>
>> ```<br>
>> lldb-Suite :: tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py<br>
>> ```<br>
>> <br>
>> On the second run but not the first, it hung all night long waiting for TestVSCode_setBreakpoints.py to terminate. I killed dotest.py to get the final results.<br>
> <br>
> We have disabled the VScode tests on Darwin because they very flaky on the bots. +Greg who added those.<br>
> <br>
> Fred<br>
> <br>
>> I currently clone <<a href="https://github.com/llvm-project/llvm-project-20170507" rel="noreferrer" target="_blank">https://github.com/llvm-project/llvm-project-20170507</a>>. I configure with `BUILD_SHARED_LIBS=true` and `-DLLVM_ENABLE_PROJECTS='clang;openmp;libcxx;libcxxabi;lldb;compiler-rt;lld;polly'`, among other options. I have to run check-all with LD_LIBRARY_PATH pointing at my build's lib directory, or there are many more LLDB failures. I believe that's not true for most test suites. I'm building and testing under Ubuntu 18.04.1.<br>
>> <br>
>> Hope that helps. I'm happy to provide more details. Just tell me where you'd like to start.<br>
>> <br>
>> Thanks.<br>
>> <br>
>> Joel<br>
>> <br>
>> On Wed, Jan 2, 2019 at 5:51 PM Kuba Mracek <<a href="mailto:mracek@apple.com" target="_blank">mracek@apple.com</a>> wrote:<br>
>> +Fred, +me<br>
>> <br>
>> For LLDB tests: I believe this got much much better recently. Are you still seeing flaky LLDB tests? Any details you can share?<br>
>> For sanitizer tests: I'm very much interesting in removing flakiness as well. Any specific tests you see as flaky?<br>
>> <br>
>> Kuba<br>
>> <br>
>>> On Jan 2, 2019, at 2:05 PM, Joel E. Denny via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> <br>
>>> Hi David, Chandler,<br>
>>> <br>
>>> I see lldb tests hang often, and then I kill the dotest process.<br>
>>> <br>
>>> I'd like to stop running check-all too, but I feel it's important when I modify FileCheck. The flakiness that Chandler mentioned makes it time-consuming to verify test results.<br>
>>> <br>
>>> Joel<br>
>>> <br>
>>> On Wed, Jan 2, 2019 at 4:41 PM Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> What you're seeing is just the fact that lit is waiting on subprocesses (select is waiting on the pipes i suspect).<br>
>>> <br>
>>> Anyways, you'll need to dig into what it is waiting on, and what *that* process is doing that is stuck to make progress.<br>
>>> <br>
>>> I've not seen anything like this, but I basically never run `check-all` these days because LLDB and sanitizer tests are too flaky. =[ I've not been able to interest anyone in fixing this either sadly.<br>
>>> <br>
>>> On Wed, Jan 2, 2019 at 10:09 AM David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> Hi,<br>
>>> <br>
>>> From time to time, I see check-all hang during running of lit tests.<br>
>>> The hang always happens at the > 90% completion stage and I'm pretty<br>
>>> sure all tests have been run and check-all is just waiting for<br>
>>> lit/python to exit. I see a single python processing running, taking<br>
>>> very little CPU time. An strace of that process shows this:<br>
>>> <br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 32168}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout)<br>
>>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1<br>
>>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0<br>
>>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = -1 EAGAIN (Resourc<br>
>>> e temporarily unavailable) <br>
>>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = -1 EAGAIN (Resourc<br>
>>> e temporarily unavailable) <br>
>>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1<br>
>>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout)<br>
>>> <br>
>>> It appears that python is waiting for some I/O or something which never<br>
>>> appears.<br>
>>> <br>
>>> Has anyone else seen this before? Any ideas of what is going on or how<br>
>>> to fix it?<br>
>>> <br>
>>> -David<br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote></div></div></div></div></div></div></div></div></div></div></div>