[lldb-dev] ScriptInterpreterPython initialization

[Zachary Turner]

Hi Greg,

I found a problem with my initialization refactor, so I want to get your
advice before I commit it.  The issue is related to the fact that
modify-python-lldb.py inserts some code at the end to automatically call
SBDebugger.Initialize() the first time anyone runs "import lldb".

When using lldb from python.  When using lldb from python, this means the
user doesn't have to call SBDebugger.Initialize() because "import lldb"
will do it automatically.  When using lldb the executable, we call
SBDebugger::Initialize() explicitly, which results in a call to this line
in ScriptInterpreterPython:

    int old_count = Debugger::TestDebuggerRefCount ();

    PyRun_SimpleString ("sys.dont_write_bytecode = 1; import
lldb.embedded_interpreter; from lldb.embedded_interpreter import
run_python_interpreter; from lldb.embedded_interpreter import
run_one_line");

    int new_count = Debugger::TestDebuggerRefCount ();

    if (new_count > old_count)
        Debugger::Terminate ();

Since this is the first time lldb is imported, it results in a call to
SBDebugger::Initialize() again.  This recursive call doesn't do anything
because it sees that g_initialized has been set to true already.  But when
it returns control back to the line after the PyRun_SimpleString(), it
tests the new ref count against the old ref count and calls
Debugger::Terminate.  But, the ref count was previously 1, so this results
in the debugger refcount being 0.  In practice it turns out this doesn't
matter, because all Debugger::Terminate() does is clear an already clear
debugger list.  And actually I can fix it by
changing SystemLifetimeManager::AddRef() to put the call to
Debugger::Initialize() before the call to m_initializer->Initialize().

But all of this is very fragile and confusing.  I have an idea for fixing
this a "better" way, but I would like your opinion.

If we remove the call to SBDebugger.Initialize() from __init__.py (by
changing modify-python-lldb.py to not insert these lines) the problems
disappear.  Now, when we write PyRun_SimpleString("import lldb") we don't
get a recursive call to SBDebugger::Initialize().  We would need to update
the test suite to explicitly call this.

I think this makes for a more clear usage pattern.  implicitly calling
SBDebugger.Initialize() just seems like a bad idea.  By making this change
we would be able to remove all of the debugger ref count testing and
conditionally calling Debugger::Terminate.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150320/bafbc197/attachment.html>