[lldb-dev] IOHandler branch has been merged into top of tree
Todd Fiala
tfiala at google.com
Tue Jan 28 11:02:31 PST 2014
Here's what I'm finding on our setup:
>> FAIL: LLDB (suite) :: TestConvenienceVariables.py (Linux
tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
2013 x86_64 x86_64)
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:
#0 0x00007f8749507e87 in ?? () from /usr/lib/python2.7/lib-dynload
/readline.so
#1 0x00007f874b6c3610 in PyOS_Readline () from /usr/lib/libpython2.7.so.1.0
#2 0x00007f874b640fad in ?? () from /usr/lib/libpython2.7.so.1.0
#3 0x00007f874b60c5d5 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#4 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#5 0x00007f874b60c650 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#6 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#7 0x00007f874b60c650 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#8 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#9 0x00007f874b60c650 in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#10 0x00007f874b60d37b in PyEval_EvalFrameEx () from
/usr/lib/libpython2.7.so.1.0
#11 0x00007f874b5cc6b5 in PyEval_EvalCodeEx () from
/usr/lib/libpython2.7.so.1.0
#12 0x00007f874b5cc9e2 in PyEval_EvalCode () from
/usr/lib/libpython2.7.so.1.0
#13 0x00007f874b5cca7c in PyRun_StringFlags () from
/usr/lib/libpython2.7.so.1.0
#14 0x00007f874b5cd6cb in PyRun_SimpleStringFlags () from
/usr/lib/libpython2.7.so.1.0
#15 0x00007f874e71cbf0 in IOHandlerPythonInterpreter::Run (this=0x19e79c0)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter
/ScriptInterpreterPython.cpp:747
#16 0x00007f874e4d36bc in lldb_private::Debugger::ExecuteIOHanders
(this=0x17cc400)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Core/Debugger.cpp:865
#17 0x00007f874e647c16 in
lldb_private::CommandInterpreter::RunCommandInterpreter
(this=0x17e03f0,
auto_handle_events=true, spawn_thread=false)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/Interpreter
/CommandInterpreter.cpp:3002
#18 0x00007f874e3c93f5 in lldb::SBDebugger::RunCommandInterpreter
(this=0x7fff9fb8c2a0,
auto_handle_events=true, spawn_thread=false)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/source/API/SBDebugger.cpp:961
#19 0x000000000040f5ae in Driver::MainLoop (this=0x7fff9fb8c280)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/tools/driver/Driver.cpp:946
#20 0x000000000040f8f4 in main (argc=3, argv=0x7fff9fb8c468,
envp=0x7fff9fb8c488)
at /mnt/ssd/work/svn/lgs/llvm/tools/lldb/tools/driver/Driver.cpp:1039
On Ubuntu 12.04 LTS x86_64, the /usr/lib/python2.7/lib-dynload/readline.so
links against GNU readline:
tfiala at tfiala2:/usr/lib/python2.7/lib-dynload$ ldd readline.so
linux-vdso.so.1 => (0x00007fff137f1000)
*libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
(0x00007fdd7d66c000)*
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fdd7d44f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd7d08e000)
libgcc_s.so.1 => /usr/local/gcc/gcc-current/lib64/libgcc_s.so.1
(0x00007fdd7ce78000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fdd7cc51000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdd7dad6000)
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 <http://thrysoee.dk/editline/>, as we found the
Ubuntu 12.04 LTS libedit-dev package was too old for some of the newer
iohandler features:
tfiala at tfiala2:~/lldb/svn/lgs/build/Debug+Asserts/bin$ ldd lldb
linux-vdso.so.1 => (0x00007fff8c579000)
*libedit.so.0 =>
/usr/local/google/home/tfiala/lldb/tools/libedit/linux-x86_64/lib/libedit.so.0
(0x00007f00fdac3000)*
liblldb.so =>
/mnt/ssd/work/svn/lgs/build/Debug+Asserts/bin/./../lib/liblldb.so
(0x00007f00f87c3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f00f858d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f00f8370000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f00f8148000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f00f7f40000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f00f7d3c000)
libstdc++.so.6 => /usr/local/gcc/gcc-current/lib64/libstdc++.so.6
(0x00007f00f7a38000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f00f773c000)
libgcc_s.so.1 => /usr/local/gcc/gcc-current/lib64/libgcc_s.so.1
(0x00007f00f7526000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f00f7165000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f00f6f62000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f00f6a65000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5
(0x00007f00f6843000)
libpanel.so.5 => /usr/lib/x86_64-linux-gnu/libpanel.so.5
(0x00007f00f663f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f00fdcf6000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007f00f63e0000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007f00f6005000)
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.
On Mon, Jan 27, 2014 at 4:38 PM, Todd Fiala <tfiala at google.com> wrote:
> 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:
>
> Failing Tests (6)
> FAIL: LLDB (suite) :: TestAliases.py (Linux tfiala2.mtv.corp.google.com3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
> FAIL: LLDB (suite) :: TestCommandScript.py (Linux
> tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
> 2013 x86_64 x86_64)
> FAIL: LLDB (suite) :: TestConvenienceVariables.py (Linux
> tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
> 2013 x86_64 x86_64)
> FAIL: LLDB (suite) :: TestConditionalBreak.py (Linux
> tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
> 2013 x86_64 x86_64)
> FAIL: LLDB (suite) :: TestDataFormatterCategories.py (Linux
> tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
> 2013 x86_64 x86_64)
> FAIL: LLDB (suite) :: TestDataFormatterGlobals.py (Linux
> tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT
> 2013 x86_64 x86_64)
>
> I'll start looking at those tomorrow if somebody doesn't beat me to them.
>
>
> On Mon, Jan 27, 2014 at 3:50 PM, Greg Clayton <gclayton at apple.com> wrote:
>
>> 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:
>>
>> 1 - Input/Output/Error streams are now handled as real streams not a push
>> style input
>> 2 - auto completion in python embedded interpreter
>> 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
>> 4 - it is now possible to use curses to drive LLDB (please try the "gui"
>> command)
>>
>> 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.
>>
>> Greg Clayton
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
>
> --
> Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
>
--
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140128/a229ca9a/attachment.html>
More information about the lldb-dev
mailing list