> On Mar 20, 2015, at 1:06 PM, Zachary Turner <ztur...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
