[lldb-dev] ScriptInterpreterPython initialization

[Greg Clayton]

> On Mar 20, 2015, at 1:06 PM, Zachary Turner <zturner at google.com> wrote:
> 
> 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?

My main concern is "things should just work". Python expects functions to be ready to be called after importing so I would like to not require people to call SBDebugger::Initialize() first after a "import lldb". What ever we have to do to make this work, we should do that.

I don't know of _any_ other python module that requires you to call some function after importing the module, so it makes sense from a C++ API perspective, but not for python.

So I would vote to do what you need to do to make the following two things happen:
- from python when it loads LLDB "import lldb" should be enough
- in the embedded interpreter we should obviously not have to call it