<div dir="ltr">Yeah I figured that wouldn't be the final solution. But I'm guessing this is exposing some kind of bad interaction that is going to (potentially) happen anywhere that python links with libreadline, which is everywhere that __APPLE__ isn't defined (so maybe wider than Linux).<div>
<br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">So we still need to figure out what is going wrong on linux with readline.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Right. At this point it might even be a manifestation of how test input/output is interacting with it. I haven't caught it happening outside of the test environment yet (although I've only tried a handful of times), although nothing in the nature of the crash screams test-only since this is crashing in a python module using readline.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> You could import "platform" in python and and set "readfunc=readfunc_stdio" for now for non darwin platforms (or anything that is readline based and causing the problem) just to get things working, but I am guessing people will really want the auto completion in the embedded python interpreter...</span></div>
<div><div><br></div><div>Ok - I may also try to work it in so that it only disables auto completion in the test environment. If we started getting bug reports around it outside of the test environment, we would know this is a bigger issue. </div>
<div><br></div><div>-Todd</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 4:11 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jan 28, 2014, at 3:52 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
<br>
> I was able to address the TestConvenienceVariables.py break with this patch (thanks for some clues on that, Greg!):<br>
><br>
> Index: test/dotest.py<br>
> ===================================================================<br>
> --- test/dotest.py (revision 200343)<br>
> +++ test/dotest.py (working copy)<br>
> @@ -873,10 +873,13 @@<br>
> pluginPath = os.path.join(scriptPath, 'plugins')<br>
> pexpectPath = os.path.join(scriptPath, 'pexpect-2.4')<br>
><br>
> - # Append script dir, plugin dir, and pexpect dir to the sys.path.<br>
> + # Put embedded pexpect at front of the load path so we ensure we<br>
> + # use that version.<br>
> + sys.path.insert(0, pexpectPath)<br>
> +<br>
> + # Append script dir and plugin dir to the sys.path.<br>
> sys.path.append(scriptPath)<br>
> sys.path.append(pluginPath)<br>
> - sys.path.append(pexpectPath)<br>
><br>
> # This is our base name component.<br>
> base = os.path.abspath(os.path.join(scriptPath, os.pardir))<br>
> Index: source/Interpreter/embedded_interpreter.py<br>
> ===================================================================<br>
> --- source/Interpreter/embedded_interpreter.py (revision 200343)<br>
> +++ source/Interpreter/embedded_interpreter.py (working copy)<br>
> @@ -86,7 +86,7 @@<br>
> code.interact(banner="Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.", readfunc=readfunc_stdio, local=local_dict)<br>
> else:<br>
> # We have a real interactive terminal<br>
> - code.interact(banner="Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.", local=local_dict)<br>
> + code.interact(banner="Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.", readfunc=readfunc_stdio, local=local_dict)<br>
> except SystemExit as e:<br>
> global g_builtin_override_called<br>
> if not g_builtin_override_called:<br>
><br>
<br>
<br>
<br>
</div></div>So we can't checkin the code above where we set "readfunc=readfunc_stdio" as this disables all auto completion as it won't use readline + rlcompleter if this is enabled. This simply identifies that the problem has something to do with readline...<br>
<br>
So we still need to figure out what is going wrong on linux with readline. You could import "platform" in python and and set "readfunc=readfunc_stdio" for now for non darwin platforms (or anything that is readline based and causing the problem) just to get things working, but I am guessing people will really want the auto completion in the embedded python interpreter...<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> The other 5 still remain.<br>
><br>
> Looking at TestAliases.py:<br>
><br>
> python ../llvm/tools/lldb/test/dotest.py -C gcc --executable `pwd`/Debug+Asserts/bin/lldb -p TestAliases.py<br>
><br>
> Yields:<br>
><br>
> Ran 2 tests in 1.613s<br>
><br>
> OK (skipped=1)<br>
> Session logs for test failures/errors/unexpected successes can be found in directory '<a href="tel:2014-01-28-15" value="+12014012815">2014-01-28-15</a>_39_58'<br>
> Fatal Python error: PyEval_SaveThread: NULL tstate<br>
> Aborted (core dumped)<br>
><br>
> Python is dumping core at this point, it looks to be in cleanup code since the test harness already reported an OK test result. The rest of the errors seem to be either identical or nearly identical to the trace below. I'll have a look at the cleanup code to see what's wrong here.<br>
><br>
> #0 0x00007f7073b52425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.<br>
> (gdb) bt<br>
> #0 0x00007f7073b52425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
> #1 0x00007f7073b55b8b in __GI_abort () at abort.c:91<br>
> #2 0x000000000053ed5d in Py_FatalError ()<br>
> #3 0x00000000004925cf in ?? ()<br>
> #4 0x000000000047f797 in ?? ()<br>
> #5 0x00007f706e4f9059 in lldb_private::PythonObject::Reset (this=0x2899a20, py_obj=0x0)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/../../include/lldb/Interpreter/PythonDataObjects.h:65<br>
> #6 0x00007f706e4f8fb5 in lldb_private::PythonObject::~PythonObject (this=0x2899a20, __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/../../include/lldb/Interpreter/PythonDataObjects.h:51<br>
> #7 0x00007f706e4fbad0 in lldb_private::ScriptInterpreterPython::~ScriptInterpreterPython (this=0x28999e0,<br>
> __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/ScriptInterpreterPython.cpp:205<br>
> #8 0x00007f706e4fbb34 in lldb_private::ScriptInterpreterPython::~ScriptInterpreterPython (this=0x28999e0,<br>
> __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/ScriptInterpreterPython.cpp:207<br>
> #9 0x00007f706e429754 in std::default_delete<lldb_private::ScriptInterpreter>::operator() (this=0x256a108,<br>
> __ptr=0x28999e0) at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:67<br>
> #10 0x00007f706e428959 in std::unique_ptr<lldb_private::ScriptInterpreter, std::default_delete<lldb_private::ScriptInterpreter> >::~unique_ptr (this=0x256a108, __in_chrg=<optimized out>)<br>
> at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:184<br>
> #11 0x00007f706e425b2b in lldb_private::CommandInterpreter::~CommandInterpreter (this=0x2569ec0,<br>
> __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2097<br>
> #12 0x00007f706e425c20 in lldb_private::CommandInterpreter::~CommandInterpreter (this=0x2569ec0,<br>
> __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2099<br>
> #13 0x00007f706e2bd49a in std::default_delete<lldb_private::CommandInterpreter>::operator() (this=0x2569da8,<br>
> __ptr=0x2569ec0) at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:67<br>
> #14 0x00007f706e2bb9ed in std::unique_ptr<lldb_private::CommandInterpreter, std::default_delete<lldb_private::CommandInterpreter> >::~unique_ptr (this=0x2569da8, __in_chrg=<optimized out>)<br>
> at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/unique_ptr.h:184<br>
> #15 0x00007f706e2b3580 in lldb_private::Debugger::~Debugger (this=0x2569a10, __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:668<br>
> #16 0x00007f706e2b368e in lldb_private::Debugger::~Debugger (this=0x2569a10, __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:671<br>
> #17 0x00007f706e2c1cba in std::_Sp_counted_ptr<lldb_private::Debugger*, (__gnu_cxx::_Lock_policy)2>::_M_dispose<br>
> (this=0x28727f0) at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:290<br>
> #18 0x00007f706e198334 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x28727f0)<br>
> at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:144<br>
> #19 0x00007f706e197de7 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x2939e78,<br>
> __in_chrg=<optimized out>) at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:546<br>
> #20 0x00007f706e19dd7c in std::__shared_ptr<lldb_private::Debugger, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr<br>
> (this=0x2939e70, __in_chrg=<optimized out>)<br>
> at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr_base.h:781<br>
> #21 0x00007f706e19dd96 in std::shared_ptr<lldb_private::Debugger>::~shared_ptr (this=0x2939e70,<br>
> __in_chrg=<optimized out>) at /usr/local/gcc/gcc-4.8.2/include/c++/4.8.2/bits/shared_ptr.h:93<br>
> #22 0x00007f706e1a7da6 in lldb::SBDebugger::~SBDebugger (this=0x2939e70, __in_chrg=<optimized out>)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/API/SBDebugger.cpp:247<br>
> ---Type <return> to continue, or q <return> to quit---<br>
> #23 0x00007f706e4543df in _wrap_delete_SBDebugger (args=0x24df4d0) at LLDBWrapPython.cpp:14646<br>
> #24 0x00000000004f7496 in PyObject_Call ()<br>
> #25 0x00000000004f87cb in PyObject_CallFunctionObjArgs ()<br>
> #26 0x00007f706e4337bd in SwigPyObject_dealloc (v=0x2a7a5d0) at LLDBWrapPython.cpp:1697<br>
> #27 0x000000000054878d in ?? ()<br>
> #28 0x000000000045d198 in ?? ()<br>
> #29 0x0000000000555d65 in ?? ()<br>
> #30 0x00000000004bef09 in PyDict_SetItem ()<br>
> #31 0x000000000044c9b9 in _PyModule_Clear ()<br>
> #32 0x00000000004369c8 in PyImport_Cleanup ()<br>
> #33 0x000000000047ec4c in Py_Finalize ()<br>
> #34 0x000000000047f148 in Py_Exit ()<br>
> #35 0x000000000047f27c in ?? ()<br>
> #36 0x0000000000424a8c in PyRun_SimpleFileExFlags ()<br>
> #37 0x0000000000425cb6 in Py_Main ()<br>
> #38 0x00007f7073b3d76d in __libc_start_main (main=0x41bb00 <main>, argc=8, ubp_av=0x7fffced281e8,<br>
> init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffced281d8)<br>
> at libc-start.c:226<br>
> #39 0x000000000041bb31 in _start ()<br>
><br>
> I'll track this one down and will get a fix in for all of them (including the patch above) in one shot.<br>
><br>
> -Todd<br>
><br>
><br>
><br>
> On Tue, Jan 28, 2014 at 1:42 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> Digging through the python readline.c code, the libedit support appears to be hardcoded to working with __APPLE__ #ifdefs --- I am not seeing an easy way to build python with libedit support under Linux.<br>
><br>
> Any ideas here? It's possible our issue is not so much a libedit/libreadline issue and more just faulty assumptions (possibly in Python's readline.so) about atomic operations that are causing the crash. I was just trying to get both Python and LLDB to be using the same one.<br>
><br>
> -Todd<br>
><br>
><br>
> On Tue, Jan 28, 2014 at 11:33 AM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> Building with libreadline-dev on Ubuntu 12.04 LTS x86_64 isn't going to work. We're using editline-specific functionality.<br>
><br>
> I'm going to try the other approach now, which is building and using a python that is built against libedit.<br>
><br>
><br>
> On Tue, Jan 28, 2014 at 11:02 AM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> Here's what I'm finding on our setup:<br>
><br>
> >> FAIL: LLDB (suite) :: TestConvenienceVariables.py (<a href="http://Linuxtfiala2.mtv.corp.google.com" target="_blank">Linuxtfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
><br>
> This test is failing most of the time. There appears to be some kind of race on the readline/libedit functionality. The embedded python that is being tested by the script is using the system readline library, which is different than the new libedit that we're using in the lldb executable. The embedded python is core dumping (seg fault) around reading a string. I'm getting a back trace like so from the lldb test process that seg faulted:<br>
><br>
> #0 0x00007f8749507e87 in ?? () from /usr/lib/python2.7/lib-dynload/readline.so<br>
> #1 0x00007f874b6c3610 in PyOS_Readline () from /usr/lib/libpython2.7.so.1.0<br>
> #2 0x00007f874b640fad in ?? () from /usr/lib/libpython2.7.so.1.0<br>
> #3 0x00007f874b60c5d5 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0<br>
> #4 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0<br>
> #5 0x00007f874b60c650 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0<br>
> #6 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0<br>
> #7 0x00007f874b60c650 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0<br>
> #8 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0<br>
> #9 0x00007f874b60c650 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0<br>
> #10 0x00007f874b60d37b in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0<br>
> #11 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0<br>
> #12 0x00007f874b5cc9e2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0<br>
> #13 0x00007f874b5cca7c in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0<br>
> #14 0x00007f874b5cd6cb in PyRun_SimpleStringFlags () from /usr/lib/libpython2.7.so.1.0<br>
> #15 0x00007f874e71cbf0 in IOHandlerPythonInterpreter::Run (this=0x19e79c0)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/ScriptInterpreterPython.cpp:747<br>
> #16 0x00007f874e4d36bc in lldb_private::Debugger::ExecuteIOHanders (this=0x17cc400)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:865<br>
> #17 0x00007f874e647c16 in lldb_private::CommandInterpreter::RunCommandInterpreter (this=0x17e03f0,<br>
> auto_handle_events=true, spawn_thread=false)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:3002<br>
> #18 0x00007f874e3c93f5 in lldb::SBDebugger::RunCommandInterpreter (this=0x7fff9fb8c2a0,<br>
> auto_handle_events=true, spawn_thread=false)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/API/SBDebugger.cpp:961<br>
> #19 0x000000000040f5ae in Driver::MainLoop (this=0x7fff9fb8c280)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/tools/driver/Driver.cpp:946<br>
> #20 0x000000000040f8f4 in main (argc=3, argv=0x7fff9fb8c468, envp=0x7fff9fb8c488)<br>
> at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/tools/driver/Driver.cpp:1039<br>
><br>
> On Ubuntu 12.04 LTS x86_64, the /usr/lib/python2.7/lib-dynload/readline.so links against GNU readline:<br>
><br>
> tfiala@tfiala2:/usr/lib/python2.7/lib-dynload$ ldd readline.so<br>
> linux-vdso.so.1 => (0x00007fff137f1000)<br>
> libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007fdd7d66c000)<br>
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd7d44f000)<br>
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd7d08e000)<br>
> libgcc_s.so.1 => /usr/local/gcc/gcc-current/lib64/libgcc_s.so.1 (0x00007fdd7ce78000)<br>
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fdd7cc51000)<br>
> /lib64/ld-linux-x86-64.so.2 (0x00007fdd7dad6000)<br>
><br>
> That makes me think that the embedded python interpreter is likely fighting with libedit.so in some way. My lldb is built with the latest config-enabled libedit, as we found the Ubuntu 12.04 LTS libedit-dev package was too old for some of the newer iohandler features:<br>
><br>
> tfiala@tfiala2:~/lldb/svn/lgs/build/Debug+Asserts/bin$ ldd lldb<br>
> linux-vdso.so.1 => (0x00007fff8c579000)<br>
> libedit.so.0 => /usr/local/google/home/tfiala/lldb/tools/libedit/linux-x86_64/lib/libedit.so.0 (0x00007f00fdac3000)<br>
> liblldb.so => /mnt/ssd/work/svn/lgs/build/Debug+Asserts/bin/./../lib/liblldb.so (0x00007f00f87c3000)<br>
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f00f858d000)<br>
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f00f8370000)<br>
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f00f8148000)<br>
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f00f7f40000)<br>
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f00f7d3c000)<br>
> libstdc++.so.6 => /usr/local/gcc/gcc-current/lib64/libstdc++.so.6 (0x00007f00f7a38000)<br>
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f00f773c000)<br>
> libgcc_s.so.1 => /usr/local/gcc/gcc-current/lib64/libgcc_s.so.1 (0x00007f00f7526000)<br>
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f00f7165000)<br>
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f00f6f62000)<br>
> libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f00f6a65000)<br>
> libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f00f6843000)<br>
> libpanel.so.5 => /usr/lib/x86_64-linux-gnu/libpanel.so.5 (0x00007f00f663f000)<br>
> /lib64/ld-linux-x86-64.so.2 (0x00007f00fdcf6000)<br>
> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f00f63e0000)<br>
> libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f00f6005000)<br>
><br>
> I'm not yet sure if this is an inherent issue with two pieces of low level code (libedit & readline) both thinking they have sole access to the input/output file descriptors (which may require them both using readline or libedit, but not both), or just a bug in assumptions on our new iohandler input handling. I'm going to see if I can get lldb to build with readline first and see if that changes the behavior. It may convert a seg fault into a failing test, which may be easier to diagnose, or it might outright solve the problem. Back after I check out the readline route.<br>
><br>
><br>
> On Mon, Jan 27, 2014 at 4:38 PM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
> FYI - these are the tests that are failing for me on Ubuntu 12.04 x86_64 with top of tree after the iohandler merge sync:<br>
><br>
> Failing Tests (6)<br>
> FAIL: LLDB (suite) :: TestAliases.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
> FAIL: LLDB (suite) :: TestCommandScript.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
> FAIL: LLDB (suite) :: TestConvenienceVariables.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
> FAIL: LLDB (suite) :: TestConditionalBreak.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
> FAIL: LLDB (suite) :: TestDataFormatterCategories.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
> FAIL: LLDB (suite) :: TestDataFormatterGlobals.py (Linux <a href="http://tfiala2.mtv.corp.google.com" target="_blank">tfiala2.mtv.corp.google.com</a> 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)<br>
><br>
> I'll start looking at those tomorrow if somebody doesn't beat me to them.<br>
><br>
><br>
> On Mon, Jan 27, 2014 at 3:50 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
> We will need everyone to make sure their buildbots are ok and get any issues fixed. This is the one and only time the input/output and error streams will be changed in this drastic of a way. The benefits are many:<br>
><br>
> 1 - Input/Output/Error streams are now handled as real streams not a push style input<br>
> 2 - auto completion in python embedded interpreter<br>
> 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use<br>
> 4 - it is now possible to use curses to drive LLDB (please try the "gui" command)<br>
><br>
> We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.<br>
><br>
> Greg Clayton<br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180">650-943-3180</a><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>