[llvm-bugs] [Bug 27181] Xcode gtests: ensure they run, not just build, on Xcode target
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Apr 4 12:45:46 PDT 2016
https://llvm.org/bugs/show_bug.cgi?id=27181
Todd Fiala <todd.fiala at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Todd Fiala <todd.fiala at gmail.com> ---
This went up in r265340:
commit 52fbbbb74f565c752fe91478ca8803afc74a266f
Author: Todd Fiala <todd.fiala at gmail.com>
Date: Mon Apr 4 19:40:29 2016 +0000
Xcode: run gtests when building the lldb-gtest target
This addresses the following task:
https://llvm.org/bugs/show_bug.cgi?id=27181 Xcode gtests: ensure they run,
not just build, on Xcode target
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@265340
91177308-0d34-0410-b5e6-96231b3b80d8
There were a couple tricky things here:
1) I had to redirect stdin to /dev/null. If I didn't, I would hit the
callstack at the end (*1) and just hang. This doesn't happen if lldb-gtest is
run in the shell or run in Xcode directly, but does happen if run from
xcodebuild like the Green Dragon CI does.
2) I had to get lldb-gtest to be able to resolve lldb to the lldb package, not
the lldb.py that happens to live in ${BUILT_PRODUCTS_DIR}. During this build
step, I temporarily move lldb.py to park.lldb.py and set PYTHONPATH to get to
the true lldb package dir within LLDB.framework. This is a bit gross. I did
try to setup a lldb-gtest run dir, but that would run into some infinite
recursions in some of the python tests. I may come back to this later.
All gtests are passing.
(*1)
2670 Thread_4808238 DispatchQueue_1: com.apple.main-thread (serial)
2670 start (in libdyld.dylib) + 1 [0x7fff8903a5ad]
2670 main (in lldb-gtest) + 90 [0x10eec20da] TestMain.cpp:47
2670 testing::UnitTest::Run() (in lldb-gtest) + 100 [0x10ee9b684]
gtest.cc:3841
2670 bool
testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool>(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*) (in lldb-gtest) + 110
[0x10eeaaa6e] gtest.cc:2142
2670 bool
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,
bool>(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*) (in lldb-gtest) + 122
[0x10eebceea] gtest.cc:2090
2670 testing::internal::UnitTestImpl::RunAllTests() (in
lldb-gtest) + 882 [0x10ee9ba12] gtest.cc:4207
2670 testing::TestCase::Run() (in lldb-gtest) + 231
[0x10ee95b17] gtest.cc:2416
2670 testing::TestInfo::Run() (in lldb-gtest) + 216
[0x10ee95078] gtest.cc:2309
2670 testing::Test::Run() (in lldb-gtest) + 115
[0x10ee94413] gtest.cc:2157
2670 void
testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*) (in lldb-gtest)
+ 110 [0x10eea8fce] gtest.cc:2142
2670 void
testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test,
void>(testing::Test*, void (testing::Test::*)(), char const*) (in lldb-gtest)
+ 122 [0x10eeb939a] gtest.cc:2090
2670 PythonTestSuite::SetUp() (in lldb-gtest) + 30
[0x10d0f9bbe] PythonTestSuite.cpp:26
2670
lldb_private::ScriptInterpreterPython::Initialize() (in lldb-gtest) + 282
[0x1101bbe8a] mutex:548
2670 std::__1::__call_once(unsigned long
volatile&, void*, void (*)(void*)) (in libc++.1.dylib) + 117 [0x7fff86b806e9]
2670 void
std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ScriptInterpreterPython::Initialize()::$_0&&>
>(void*) (in lldb-gtest) + 91 [0x1101d1c3b] __functional_base:416
2670
lldb_private::ScriptInterpreterPython::Initialize()::$_0::operator()() const
(in lldb-gtest) + 17 [0x1101d1c61] ScriptInterpreterPython.cpp:333
2670
lldb_private::ScriptInterpreterPython::InitializePrivate() (in lldb-gtest) +
815 [0x1101d10af] ScriptInterpreterPython.cpp:3127
2670 PyRun_SimpleStringFlags (in
Python) + 69 [0x1144c0b53]
2670 PyRun_StringFlags (in Python) +
109 [0x1144c0bff]
2670 ??? (in Python) load address
0x11441e000 + 0xa2a42 [0x1144c0a42]
2670 PyEval_EvalCode (in Python)
+ 54 [0x1144a0d8c]
2670 PyEval_EvalCodeEx (in
Python) + 1583 [0x1144a13c1]
2670 PyEval_EvalFrameEx (in
Python) + 7481 [0x1144a32ec]
2670
PyEval_CallObjectWithKeywords (in Python) + 165 [0x1144a6e83]
2670 PyObject_Call (in
Python) + 99 [0x114428202]
2670 ??? (in Python)
load address 0x11441e000 + 0x7ea0a [0x11449ca0a]
2670
PyImport_ImportModuleLevel (in Python) + 1139 [0x1144b6f5b]
2670 ??? (in
Python) load address 0x11441e000 + 0x99d77 [0x1144b7d77]
2670 ??? (in
Python) load address 0x11441e000 + 0x9a1b1 [0x1144b81b1]
2670 ??? (in
Python) load address 0x11441e000 + 0x9a9d4 [0x1144b89d4]
2670 ??? (in
Python) load address 0x11441e000 + 0x9a74f [0x1144b874f]
2670
PyImport_ExecCodeModuleEx (in Python) + 241 [0x1144b5a37]
2670
PyEval_EvalCode (in Python) + 54 [0x1144a0d8c]
2670
PyEval_EvalCodeEx (in Python) + 1583 [0x1144a13c1]
2670
PyEval_EvalFrameEx (in Python) + 11609 [0x1144a430c]
2670 ??? (in Python) load address 0x11441e000 + 0x89541 [0x1144a7541]
2670 PyEval_EvalFrameEx (in Python) + 13400 [0x1144a4a0b]
2670 _wrap_SBDebugger_Initialize(_object*, _object*) (in _lldb.so) + 73
[0x114d013b9] LLDBWrapPython.cpp:23919
2670 lldb::SBDebugger::Initialize() (in _lldb.so) + 524 [0x114c3dbec]
SBDebugger.cpp:145
2670
lldb_private::SystemLifetimeManager::Initialize(std::__1::unique_ptr<lldb_private::SystemInitializer,
std::__1::default_delete<lldb_private::SystemInitializer> >,
llvm::sys::DynamicLibrary (*)(std::__1::shared_ptr<lldb_private::Debugger>
const&, lldb_private::FileSpec const&, lldb_private::Error&)) (in _lldb.so) +
675 [0x1193bdc33] SystemLifetimeManager.cpp:43
2670 lldb_private::SystemInitializerFull::Initialize() (in _lldb.so) +
60 [0x114c20fcc] SystemInitializerFull.cpp:280
2670 lldb_private::ScriptInterpreterPython::Initialize() (in _lldb.so)
+ 282 [0x119ef69da] mutex:548
2670 std::__1::__call_once(unsigned long volatile&, void*, void
(*)(void*)) (in libc++.1.dylib) + 117 [0x7fff86b806e9]
2670 void
std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ScriptInterpreterPython::Initialize()::$_0&&>
>(void*) (in _lldb.so) + 91 [0x119f0c78b] __functional_base:416
2670
lldb_private::ScriptInterpreterPython::Initialize()::$_0::operator()() const
(in _lldb.so) + 17 [0x119f0c7b1] ScriptInterpreterPython.cpp:333
2670 lldb_private::ScriptInterpreterPython::InitializePrivate()
(in _lldb.so) + 850 [0x119f0bc22] ScriptInterpreterPython.cpp:3128
2670 (anonymous
namespace)::InitializePythonRAII::~InitializePythonRAII() (in _lldb.so) + 21
[0x119f0c4e5] ScriptInterpreterPython.cpp:120
2670 (anonymous
namespace)::InitializePythonRAII::~InitializePythonRAII() (in _lldb.so) + 216
[0x119f0c708] ScriptInterpreterPython.cpp:138
2670 lldb_private::TerminalState::Restore() const (in
_lldb.so) + 164 [0x11977c034] Terminal.cpp:192
2670 tcsetattr (in libsystem_c.dylib) + 119
[0x7fff976ac29a]
2670 ioctl (in libsystem_kernel.dylib) + 159
[0x7fff8486ee27]
2670 __ioctl (in libsystem_kernel.dylib) + 10
[0x7fff84871872]
Total number in stack (recursive counted multiple, when >=5):
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160404/4be0015e/attachment.html>
More information about the llvm-bugs
mailing list