[lldb-dev] [llvm-dev] [lit] check-all hanging

Sat Jan 5 09:47:51 PST 2019

On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss <friss at apple.com> wrote:

>
>
> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny <jdenny.ornl at gmail.com> wrote:
> >
> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss <friss at apple.com> wrote:
> > -llvm-dev + lldb-dev for the lldv test failures.
> >
> >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny <jdenny.ornl at 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 <mracek at 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-dev at 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-dev at 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-dev at 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-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190105/0d69cfdb/attachment-0001.html>