SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

Subprojects LLDB
1

Hey again,

I've noticing segfaults after r262863
(dc5ef2da510f3adba99cd8b2fe18c2e6d417227d).
Could you try reproducing this bug with this code please?

int main() {
  using namespace lldb;

  SBDebugger::Initialize();

  SBDebugger debugger = SBDebugger::Create(true);
  if(!debugger.IsValid()) {
    return 1;
  }

  SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
  if(!target.IsValid()) {
    return 1;
  }

  const char* args = { "/home/dev/helloWorld/main", 0 };
  const char* env = { 0 };

  SBLaunchInfo launch_info(args);
  launch_info.SetEnvironmentEntries(env, true);
  launch_info.SetWorkingDirectory("/home/dev/helloWorld");
  launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);

  SBError error;
  SBProcess process = target.Launch(launch_info, error);

  return 0;
}

I tried to build lldb with and without the above commit and it turns
out that the revision is causing the segfault when simply running that
code (When it's exiting).

This is the backtrace:

#0 0x0000555555b03b00 in ?? ()
#1 0x00007ffff71be1aa in
lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
from /usr/lib/liblldb.so.3.8.0
#2 0x00007ffff748b674 in
lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
const*, unsigned long, StringExtractorGDBRemote&, bool) () from
/usr/lib/liblldb.so.3.8.0
#3 0x00007ffff748e89d in
lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
#4 0x00007ffff746fdab in
lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
() from /usr/lib/liblldb.so.3.8.0
#5 0x00007ffff733938b in std::_Function_handler<void
(lldb_private::BreakpointSite*),
lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
const&, lldb_private::BreakpointSite*&&) () from
/usr/lib/liblldb.so.3.8.0
#6 0x00007ffff716ae4f in
lldb_private::BreakpointSiteList::ForEach(std::function<void
(lldb_private::BreakpointSite*)> const&) () from
/usr/lib/liblldb.so.3.8.0
#7 0x00007ffff733ba9f in
lldb_private::Process::DisableAllBreakpointSites() () from
/usr/lib/liblldb.so.3.8.0
#8 0x00007ffff734a58c in lldb_private::Process::Destroy(bool) () from
/usr/lib/liblldb.so.3.8.0
#9 0x00007ffff734aa2d in lldb_private::Process::Finalize() () from
/usr/lib/liblldb.so.3.8.0
#10 0x00007ffff71d3fe0 in lldb_private::Debugger::Clear() () from
/usr/lib/liblldb.so.3.8.0
#11 0x00007ffff71d97cf in lldb_private::Debugger::~Debugger() () from
/usr/lib/liblldb.so.3.8.0
#12 0x00007ffff71da0c8 in
std::_Sp_counted_ptr<lldb_private::Debugger*,
(__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
/usr/lib/liblldb.so.3.8.0
#13 0x00007ffff71cdceb in
std::vector<std::shared_ptr<lldb_private::Debugger>,
std::allocator<std::shared_ptr<lldb_private::Debugger> > >::~vector()
() from /usr/lib/liblldb.so.3.8.0
#14 0x00007ffff60d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
#15 0x00007ffff60d9c85 in exit () from /usr/lib/libc.so.6
#16 0x00007ffff60c4717 in __libc_start_main () from /usr/lib/libc.so.6
#17 0x0000555555554f69 in _start ()

2

lldb doesn't currently work if you leave the process of cleaning up to the C++ destructor chain. You need to call Debugger::Destroy on your way out.

I think there's a bunch more cleanup than just the broadcaster/listener stuff before we'll do this right.

Jim

3

Ah, Thanks adding Debugger::Destroy at the end of my code made the
segfaults disappear.
Also as far as I understood the lldb code (Core/Debugger.cpp) it
should also be possible to call SBDebugger::Terminate() for "destroy"
all instances of lldb related objects.

4

Yes, that should work too. The thing that doesn't work is to just let the C++ destructor chain tear down the debuggers you've made. It should be possible to make that work, but nobody's had time to make that happen, and given you can avoid the crashes if you exit cleanly, it hasn't been a terribly high priority.

Jim