[lldb-dev] [PATCH] For SBDebugger::Create assertion failure
Greg Clayton
gclayton at apple.com
Tue Oct 7 17:10:43 PDT 2014
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 <mg11 at 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 at 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 at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list