On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss <fr...@apple.com> wrote:
> > > > On Jan 4, 2019, at 7:30 AM, Joel E. Denny <jdenny.o...@gmail.com> wrote: > > > > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss <fr...@apple.com> wrote: > > -llvm-dev + lldb-dev for the lldv test failures. > > > >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny <jdenny.o...@gmail.com> > wrote: > >> > >> All, > >> > >> 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. > >> > >> I ran check-all a couple of times last night at r350238, which I pulled > yesterday. Here are the results: > >> > >> ``` > >> ******************** > >> Testing Time: 5043.24s > >> ******************** > >> Unexpected Passing Tests (2): > >> lldb-Suite :: functionalities/asan/TestMemoryHistory.py > >> lldb-Suite :: functionalities/asan/TestReportData.py > >> > >> ******************** > >> Failing Tests (54): > >> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp > >> Clang :: Modules/ExtDebugInfo.cpp > >> Clang :: Modules/using-directive-redecl.cpp > >> Clang :: Modules/using-directive.cpp > >> Clang :: PCH/chain-late-anonymous-namespace.cpp > >> Clang :: PCH/cxx-namespaces.cpp > >> Clang :: PCH/namespaces.cpp > >> LLDB :: ExecControl/StopHook/stop-hook-threads.test > >> LeakSanitizer-AddressSanitizer-x86_64 :: > TestCases/Linux/use_tls_dynamic.cc > >> LeakSanitizer-Standalone-x86_64 :: > TestCases/Linux/use_tls_dynamic.cc > >> MemorySanitizer-X86_64 :: dtls_test.c > >> MemorySanitizer-lld-X86_64 :: dtls_test.c > >> lldb-Suite :: > functionalities/register/register_command/TestRegisters.py > >> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py > > > > It’s hard to diagnose dotest failures without the log. > > > > (My last reply to this was rejected by the list because I wasn't > subscribed. Trying again.) > > > > 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: > > > > ``` > > FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py > (59083 of 59736) > > ******************** TEST 'lldb-Suite :: > tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED ******************** > > lldb version 8.0.0 > > LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin > > LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin > > Libc++ tests will not be run because: Unable to find libc++ installation > > Skipping following debug info categories: ['dsym', 'gmodules'] > > > > Session logs for test failures/errors/unexpected successes will go into > directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces' > > 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 > > 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) > > 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) > > lldb-server exiting... > > 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) > > 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) > > lldb-server exiting... > > ====================================================================== > > FAIL: test_grp_register_save_restore_works_no_suffix_llgs > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", > line 144, in wrapper > > func(*args, **kwargs) > > 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 > > self.grp_register_save_restore_works(USE_THREAD_SUFFIX) > > 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 > > context = self.expect_gdbremote_sequence() > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", > line 713, in expect_gdbremote_sequence > > self.logger) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 261, in expect_lldb_gdbserver_replay > > asserter, content, context=context) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 564, in assert_match > > self._assert_exact_payload_match(asserter, actual_packet) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 518, in _assert_exact_payload_match > > assert_packets_equal(asserter, actual_packet, self.exact_payload) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 159, in assert_packets_equal > > asserter.assertEqual(actual_stripped, expected_stripped) > > AssertionError: '$E77' != '$OK' > > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8 > > ====================================================================== > > FAIL: test_grp_register_save_restore_works_with_suffix_llgs > (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", > line 144, in wrapper > > func(*args, **kwargs) > > 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 > > self.grp_register_save_restore_works(USE_THREAD_SUFFIX) > > 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 > > context = self.expect_gdbremote_sequence() > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", > line 713, in expect_gdbremote_sequence > > self.logger) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 261, in expect_lldb_gdbserver_replay > > asserter, content, context=context) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 564, in assert_match > > self._assert_exact_payload_match(asserter, actual_packet) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 518, in _assert_exact_payload_match > > assert_packets_equal(asserter, actual_packet, self.exact_payload) > > File > "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", > line 159, in assert_packets_equal > > asserter.assertEqual(actual_stripped, expected_stripped) > > AssertionError: '$E77' != '$OK' > > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8 > > ---------------------------------------------------------------------- > > Ran 4 tests in 22.052s > > I’m not familiar with the lldb-server tests. Pavel might know what Error > 77 is? > > > RESULT: FAILED (0 passes, 2 failures, 0 errors, 2 skipped, 0 expected > failures, 0 unexpected successes) > > > > ******************** > > ``` > > > > > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestDictionaryResolutionWithDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestExtractingUInt64ThroughStructuredData > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionNoDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionWithDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestInstanceNameResolutionNoDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestModuleNameResolutionNoDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestObjectAttributes > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestOwnedReferences > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonByteArray > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonBytes > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableCheck > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableInvoke > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryManipulation > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryToStructuredDictionary > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryValueEquality > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonFile > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonInteger > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStr > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStructuredInteger > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListManipulation > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListToStructuredList > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListValueEquality > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonString > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStr > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStructuredString > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList2 > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleSize > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleToStructuredList > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleValues > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestResetting > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestTypeNameResolutionNoDot > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAcquisitionSemantics > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreChanged > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreSemantics > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestDiscardSemantics > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestExceptionStateChecking > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestManualRestoreSemantics > >> lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics > > > > Those unit test failures don’t ring a bell. Anyone’s seen this? Here > too, knowing exactly the error message would help. > > > > Here's the lit output for the last one: > > > > ``` > > FAIL: lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics > (59324 of 59736) > > ******************** TEST 'lldb-Unit :: > ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics' > FAILED ******************** > > Note: Google Test filter = PythonExceptionStateTest.TestResetSemantics > > [==========] Running 1 test from 1 test case. > > [----------] Global test environment set-up. > > [----------] 1 test from PythonExceptionStateTest > > [ RUN ] PythonExceptionStateTest.TestResetSemantics > > 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. > > 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. > 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. Joel > Fred > > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x39)[0x7fc0daf41b29] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(+0x32ecd9)[0x7fc0daf41cd9] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(_ZN4llvm3sys17RunSignalHandlersEv+0x76)[0x7fc0daf3fd86] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMSupport.so.8svn(+0x32f37b)[0x7fc0daf4237b] > > /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7fc0e2a48890] > > /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7fc0d7589e97] > > /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7fc0d758b801] > > /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7fc0d757b39a] > > /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7fc0d757b412] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMCodeGen.so.8svn(+0x5d7f5e)[0x7fc0cffcbf5e] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libLLVMCodeGen.so.8svn(+0x5d7a07)[0x7fc0cffcba07] > > /usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1(+0x6db7a1)[0x7fc0c8c2d7a1] > > /lib64/ld-linux-x86-64.so.2(+0x10733)[0x7fc0e2c65733] > > /lib64/ld-linux-x86-64.so.2(+0x151ff)[0x7fc0e2c6a1ff] > > /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_exception+0x6f)[0x7fc0d76b22df] > > /lib64/ld-linux-x86-64.so.2(+0x147ca)[0x7fc0e2c697ca] > > /lib/x86_64-linux-gnu/libdl.so.2(+0xf96)[0x7fc0daa0ff96] > > /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_exception+0x6f)[0x7fc0d76b22df] > > /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_error+0x2f)[0x7fc0d76b236f] > > /lib/x86_64-linux-gnu/libdl.so.2(+0x1735)[0x7fc0daa10735] > > /lib/x86_64-linux-gnu/libdl.so.2(dlopen+0x71)[0x7fc0daa10051] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(_PyImport_GetDynLoadFunc+0x120)[0x7fc0e21dd4f0] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(_PyImport_LoadDynamicModule+0x70)[0x7fc0e2167c80] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4afe)[0x7fc0e21ebafe] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x151e91)[0x7fc0e2168e91] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x152176)[0x7fc0e2169176] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x2f5)[0x7fc0e2169565] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0xb4de4)[0x7fc0e20cbde4] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fc0e206b333] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fc0e21f57a7] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3909)[0x7fc0e20c1ac9] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc0e21f6278] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc0e20be029] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0xac)[0x7fc0e21e61cc] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4462)[0x7fc0e21eb462] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4a3e)[0x7fc0e21eba3e] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x1d4d4a)[0x7fc0e21ebd4a] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0x151e91)[0x7fc0e2168e91] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x122)[0x7fc0e2169392] > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(+0xb4de4)[0x7fc0e20cbde4] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fc0e206b333] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fc0e21f57a7] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3909)[0x7fc0e20c1ac9] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7fc0e21f6278] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7fc0e20be029] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7fc0e2161546] > > > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_SimpleStringFlags+0x3b)[0x7fc0e21615db] > > > /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x4d3cd2] > > > /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x4863c8] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x7e)[0x7fc0e25f482e] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x72)[0x7fc0e25dfa22] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing4Test3RunEv+0x74)[0x7fc0e25cd004] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8TestInfo3RunEv+0xe3)[0x7fc0e25cd913] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8TestCase3RunEv+0xec)[0x7fc0e25cde6c] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x2e1)[0x7fc0e25d35b1] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc+0x7e)[0x7fc0e25f801e] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS0_12UnitTestImplEbEET0_PT_MS4_FS3_vEPKc+0x72)[0x7fc0e25e17c2] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest.so.8svn(_ZN7testing8UnitTest3RunEv+0xc2)[0x7fc0e25d32a2] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest_main.so.8svn(+0xbe1)[0x7fc0e2834be1] > > > /home/jdenny/ornl/llvm-mono-git-build/lib/libgtest_main.so.8svn(main+0x148)[0x7fc0e2834bb8] > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fc0d756cb97] > > > /home/jdenny/ornl/llvm-mono-git-build/tools/lldb/unittests/ScriptInterpreter/Python/./ScriptInterpreterPythonTests[0x47196a] > > ``` > > > > Joel > > > > > >> Expected Passes : 57489 > >> Expected Failures : 276 > >> Unsupported Tests : 1883 > >> Unexpected Passes : 2 > >> Unexpected Failures: 54 > >> > >> 14 warning(s) in tests. > >> FAILED: CMakeFiles/check-all > >> ``` > >> > >> I immediately ran it again and saw one new unexpected fail: > >> > >> ``` > >> lldb-Suite :: tools/lldb-mi/syntax/TestMiSyntax.py > >> ``` > > > > Adrian, do we have remaining flakiness in the MI tests? Is this one of > the GSoc tests? > > > >> and one new unresolved test: > >> > >> ``` > >> lldb-Suite :: > tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py > >> ``` > >> > >> 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. > > > > We have disabled the VScode tests on Darwin because they very flaky on > the bots. +Greg who added those. > > > > Fred > > > >> I currently clone < > https://github.com/llvm-project/llvm-project-20170507>. 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. > >> > >> Hope that helps. I'm happy to provide more details. Just tell me > where you'd like to start. > >> > >> Thanks. > >> > >> Joel > >> > >> On Wed, Jan 2, 2019 at 5:51 PM Kuba Mracek <mra...@apple.com> wrote: > >> +Fred, +me > >> > >> For LLDB tests: I believe this got much much better recently. Are you > still seeing flaky LLDB tests? Any details you can share? > >> For sanitizer tests: I'm very much interesting in removing flakiness as > well. Any specific tests you see as flaky? > >> > >> Kuba > >> > >>> On Jan 2, 2019, at 2:05 PM, Joel E. Denny via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >>> > >>> Hi David, Chandler, > >>> > >>> I see lldb tests hang often, and then I kill the dotest process. > >>> > >>> 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. > >>> > >>> Joel > >>> > >>> On Wed, Jan 2, 2019 at 4:41 PM Chandler Carruth via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >>> What you're seeing is just the fact that lit is waiting on > subprocesses (select is waiting on the pipes i suspect). > >>> > >>> Anyways, you'll need to dig into what it is waiting on, and what > *that* process is doing that is stuck to make progress. > >>> > >>> 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. > >>> > >>> On Wed, Jan 2, 2019 at 10:09 AM David Greene via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >>> Hi, > >>> > >>> From time to time, I see check-all hang during running of lit tests. > >>> The hang always happens at the > 90% completion stage and I'm pretty > >>> sure all tests have been run and check-all is just waiting for > >>> lit/python to exit. I see a single python processing running, taking > >>> very little CPU time. An strace of that process shows this: > >>> > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 32168}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout) > >>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 > >>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, > NULL, ffffffff) = 0 > >>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, > NULL, ffffffff) = -1 EAGAIN (Resourc > >>> e temporarily unavailable) > > >>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> futex(0x3bcc8c0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, > NULL, ffffffff) = -1 EAGAIN (Resourc > >>> e temporarily unavailable) > > >>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 > >>> futex(0x3bcc8c0, FUTEX_WAKE_PRIVATE, 1) = 1 > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> select(0, NULL, NULL, NULL, {0, 50000}) = 0 (Timeout) > >>> > >>> It appears that python is waiting for some I/O or something which never > >>> appears. > >>> > >>> Has anyone else seen this before? Any ideas of what is going on or how > >>> to fix it? > >>> > >>> -David > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-...@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-...@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-...@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
