[lldb-dev] LLDB causes application to 'stopped'
Eran Ifrah
eran.ifrah at gmail.com
Sat Mar 29 09:52:24 PDT 2014
Hello Greg,
I tried as you suggested and copared the various flags (what I could see in
the debugger) and nothing is modified from the first call to:
stdin_tty_state.Save(STDIN_FILENO, false); (ScriptInterpreterPython.cpp,
2527)
until the last call to stdin_tty_state.Restore()
commenting this line ("stdin_tty_state.Restore()") fixes the problem for
me.
I also played a bit with lldb from the command line and it seems fine to me
;)
Eran
On Mon, Mar 24, 2014 at 8:59 PM, Eran Ifrah <eran.ifrah at gmail.com> wrote:
>
>
>
> On Mon, Mar 24, 2014 at 7:12 PM, Greg Clayton <gclayton at apple.com> wrote:
>
>>
>> On Mar 24, 2014, at 2:31 AM, Eran Ifrah <eran.ifrah at gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Let me first explain what I am trying to do here:
>> > I have written an LLDB plugin for codelite IDE which so far supports
>> limited functionality, but as soon as I will overcome all the small
>> distractions, I expect it to be fully functional
>> > in matter of days.
>> >
>> > However, I have encountered yet another annoyance:
>> >
>> > The plugin is hosted within codelite (plugins are shared objects). On
>> startup, codelite loads all the plugins available for it and calls their
>> initialization method.
>> > The LLDB plugin initialization includes this line:
>> >
>> > lldb::SBDebugger::Initialize();
>> >
>> > However, this line will work properly unless I have started codelite in
>> the background :P
>> >
>> > So by starting codelite like this:
>> > $codelite &
>> >
>> > LLDB will cause codelite process to 'stop' (the backtrace goes deep
>> into libpython terminal initialization)
>> > bringing codelite to the foreground fixes this (you can now put
>> codelite in the background once again without any problems, since we passed
>> the 'Initialize' phase)
>> >
>> > The same can be observed when starting lldb in the background (i.e. you
>> will get the same backtrace):
>> > $lldb&
>> >
>> >
>> > Any ideas on how to overcome this? Maybe building lldb without python
>> support?
>>
>> The python support is one of the biggest strengths of LLDB and allows a
>> lot of great things to be done. I would suggest trying to figure out what
>> is going on and I am guessing things are going to be locking up within the
>> following function:
>>
>> ScriptInterpreterPython::InitializePrivate()
>>
>> I see the same issue on MacOSX:
>>
>> 9396 Thread_4108442 DispatchQueue_1: com.apple.main-thread (serial)
>> 9396 start (in libdyld.dylib) + 1 [0x7fff8eb175fd]
>> 9396 main (in lldb) + 27 [0x107a1720f]
>> 9396 lldb_private::Initialize() (in LLDB) + 268 [0x108b66c2c]
>> 9396
>> lldb_private::ScriptInterpreterPython::InitializePrivate() (in LLDB) + 742
>> [0x108c8da42]
>> 9396 lldb_private::TerminalState::Restore() const (in
>> LLDB) + 74 [0x108c69268]
>> 9396 tcsetattr (in libsystem_c.dylib) + 114
>> [0x7fff8f7485a9]
>> 9396 ioctl (in libsystem_kernel.dylib) + 159
>> [0x7fff96508b00]
>> 9396 __ioctl (in libsystem_kernel.dylib) + 10
>> [0x7fff9650a24a]
>>
>> Yes, sorry - I forgot to paste the backtrace. But its identical to what I
> was experiencing
>
>> So the issue seems to be with the:
>>
>> TerminalState stdin_tty_state;
>> stdin_tty_state.Save(STDIN_FILENO, false);
>>
>> and it locks up when we call:
>>
>>
>> stdin_tty_state.Restore();
>>
>> You might run this in the foreground and see exactly what is saved during
>> the call to stdin_tty_state.Save(...) and then add another:
>>
>> TerminalState stdin_tty_state2;
>> stdin_tty_state2.Save(STDIN_FILENO, false);
>>
>> Then compare what is in stdin_tty_state with stdin_tty_state2 and see if
>> python modified anything in the terminal states. If they are the same, we
>> can probably skip these calls and avoid this issue.
>>
>> I will try this ( first I need to build lldb/llvm/clang in debug mode ...)
>
>> >
>> >
>> > P.S:
>> >
>> > Other annoyance I encountered which might worth written to this mailing
>> list (so at least they can be archived so other people might find them
>> while googling ;) )
>> > * Make sure you application is not blocking any SIGCHLD signals or the
>> debugger will fail to report the process events correctly (
>> SBProcess::WaitForEvent )
>>
>>
>> How do you have an IDE that doesn't reap child processes? IDEs will kick
>> off compilers and linkers and many other child processes and if you aren't
>> reaping them you are creating zombies.
>>
>> Hmm, that was not what I meant...
> I installed my own SIGCHLD (which calls ::waitpid() to retrieve the exit
> status of a process + avoid zombies)
>
> However, since my handler did not call in turn to the original signal
> handler I encountered this problem.
> I did not realize that LLDB was relying on it so it was a nightmare to
> figure this one out ;)
>
> I am glad you figured this out, and we should look at a way to make sure
>> SIGCHILD isn't set to ignore and warn when launching child processes from
>> within LLDB.
>>
>>
>> >
>> >
>> >
>> > --
>> > Eran Ifrah
>> > Author of codelite, a cross platform open source C/C++ IDE:
>> http://www.codelite.org
>> > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Eran Ifrah
> Author of codelite, a cross platform open source C/C++ IDE:
> http://www.codelite.org
> wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
>
--
Eran Ifrah
Author of codelite, a cross platform open source C/C++ IDE:
http://www.codelite.org
wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140329/bd30e96d/attachment.html>
More information about the lldb-dev
mailing list