It is quite common for shared libraries to have initialize and terminate calls.
We have this in LLDB.
I would rather not have to look through all API calls that might require LLDB
to be initialized and have to possibly manually call SBDebugger::Initialize()
in there. The initialization does quite a bit and the assertion quickly should
tell you that you must call SBDebugger::Initialize() first. If it isn't clear
from the assertion, we can change the assertion to be more descriptive. But
again, many other classes in the lldb::SB* API have functions that might be
able to be used without having to start with a debugger, so I would rather not
have to go through all of the API and add the "init the debugger if not already
initialized".
This also allows you to use LLDB as a shared library and do:
SBDebugger::Initialize()
// Do something that takes up a bunch of memory
SBDebugger::Terminate()
This allows all resources to be freed up after the Terminate() call.
So I vote to leave things as is.
Greg
> On Oct 3, 2014, at 5:52 AM, Matthew Gardiner <m...@csr.com> wrote:
>
> The assertion failure in detail is this:
>
> (gdb) bt
> #0 0x0000003675e35c39 in raise () from /lib64/libc.so.6
> #1 0x0000003675e37348 in abort () from /lib64/libc.so.6
> #2 0x0000003675e2eb96 in __assert_fail_base () from /lib64/libc.so.6
> #3 0x0000003675e2ec42 in __assert_fail () from /lib64/libc.so.6
> #4 0x00007fd956ee1e29 in lldb_private::Debugger::Debugger (this=0xd478f0,
> log_callback=0x0, baton=0x0)
> at
> /home/mg11/src/main/devtools/main/llvm/tools/lldb/source/Core/Debugger.cpp:649
> #5 0x00007fd956ee13a3 in lldb_private::Debugger::CreateInstance
> (log_callback=0x0, baton=0x0)
> at
> /home/mg11/src/main/devtools/main/llvm/tools/lldb/source/Core/Debugger.cpp:530
> #6 0x00007fd9572456de in lldb::SBDebugger::Create (source_init_files=0x1,
> callback=0x0, baton=0x0)
> at
> /home/mg11/src/main/devtools/main/llvm/tools/lldb/source/API/SBDebugger.cpp:172
> #7 0x00007fd95724560d in lldb::SBDebugger::Create (source_init_files=0x1)
> at
> /home/mg11/src/main/devtools/main/llvm/tools/lldb/source/API/SBDebugger.cpp:153
> #8 0x00000000004008d8 in main () at main.cpp:10
> (gdb) fr 4
> #4 0x00007fd956ee1e29 in lldb_private::Debugger::Debugger (this=0xd478f0,
> log_callback=0x0, baton=0x0)
> at
> /home/mg11/src/main/devtools/main/llvm/tools/lldb/source/Core/Debugger.cpp:649
> 649 assert (default_platform_sp.get());
> (gdb) list
> 644 if (log_callback)
> 645 m_log_callback_stream_sp.reset (new StreamCallback
> (log_callback, baton));
> 646 m_command_interpreter_ap->Initialize ();
> 647 // Always add our default platform to the platform list
> 648 PlatformSP default_platform_sp (Platform::GetHostPlatform());
> 649 assert (default_platform_sp.get());
> 650 m_platform_list.Append (default_platform_sp, true);
> 651
> 652 m_collection_sp->Initialize (g_properties);
> 653 m_collection_sp->AppendProperty (ConstString("target"),
> (gdb)
>
>
>
> On Fri, 2014-10-03 at 13:46 +0100, Matthew Gardiner wrote:
>> Hi folks,
>>
>> Whilst starting to play with the lldb C++ API, I've noticed that this
>> simple little program causes an assertion failure (and hence a core
>> dump).
>>
>> #include <cstdio>
>> #include "lldb/API/LLDB.h"
>>
>> int main()
>> {
>> fprintf(stderr, "lldb-app\n");
>> // lldb::SBDebugger::Initialize();
>> lldb::SBDebugger dbgr = lldb::SBDebugger::Create(true);
>> fprintf(stderr, "SBDebugger::Create!\n");
>> return 0;
>> }
>>
>> As guessed, by uncommenting out the Initialize call, the assertion is
>> satisfied by Create and friends, and the code runs to completion.
>>
>> To me, this is bad on 2 counts:
>>
>> 1. If Create depends on Initialize then Initialize should be called
>> internally.
>> 2. From a public API perspective, even if Create and Initialize need to
>> be called separately, a crash (failed assert) seems a little harsh.
>> Shouldn't an error return (or exception throw) be used to communicate
>> the user's mistake in this case?
>>
>> I did some digging into SBDebugger::Initialize and it seems safe for
>> this to be called internally by Create.
>>
>> So I'm proposing that I fix this issue with following patch:
>>
>> Index: source/API/SBDebugger.cpp
>> ===================================================================
>> --- source/API/SBDebugger.cpp (revision 218974)
>> +++ source/API/SBDebugger.cpp (working copy)
>> @@ -159,6 +159,8 @@
>> {
>> Log *log(GetLogIfAllCategoriesSet (LIBLLDB_LOG_API));
>>
>> + Initialize();
>> +
>> SBDebugger debugger;
>>
>> // Currently we have issues if this function is called
>> simultaneously on two different
>> @@ -210,6 +212,8 @@
>> sstr.GetData());
>> }
>>
>> + Terminate();
>> +
>> Debugger::Destroy (debugger.m_opaque_sp);
>>
>> if (debugger.m_opaque_sp.get() != NULL)
>>
>>
>> Please shout out if you don't want me to.
>>
>> thanks
>> Matt
>>
>>
>>
>>
>> Member of the CSR plc group of companies. CSR plc registered in England and
>> Wales, registered number 4187346, registered office Churchill House,
>> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>> More information can be found at
>> www.csr.com. Keep up to date with CSR on our technical blog,
>> www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
>> www.youtube.com/user/CSRplc, Facebook,
>> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
>> www.twitter.com/CSR_plc
>> .
>> New for 2014, you can now access the wide range of products powered by aptX
>> at
>> www.aptx.com
>> .
>> _______________________________________________
>> lldb-dev mailing list
>>
>> lldb-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>>
>> To report this email as spam click
>> https://www.mailcontrol.com/sr/pilrSd6CXBDGX2PQPOmvUj!GOBh06pKKo4kkp2B6Y080nTmNNKVHT4SNd1RosIFWqz8LAxcsry5jDxGYc2QXWA==
>> .
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
