lldb crash on osx

Hi There,

Firstly I apologise if this the incorrect forum for something like this, but it’s a kind of “you’re my only hope” type situation. I am currently in the process of porting a 2.5 million line pc code base to OSX and after a year of compiler wrangling and team coding standards changes I’m pretty much there. However, we have had to keep upgrading XCode due to the support of C++11 being slow in coming. However, now with XCode 5 we have all the features we need, there is one small problem though, XCode crashes when trying to debug our code. I eventually traced this to the fact that the lldb that ships with XCode5 crashes when trying to attach to the exe. I found this out by running lldb against our exe from the command line. I then tried downloading the latest lldb from svn and building it, which yielded a version that would attach to the exe and run it, but would crash in a very similar way when trying to perform any debugging operations, such as a backtrace. As a last ditch effort I tried debugging lldb debugging our exe (fun times), and got the following output and call stack.

If anyone could shed some light on it, then it would be great. I’m afraid that I am unable to provide reproduction methods, due to the size and proprietary nature of the code base, I am happy to provide any additional information that may be required though.

(lldb) bt

lldb(7515,0x7fff7b4b2180) malloc: *** error for object 0x104186080: incorrect checksum for freed object - object was probably modified after being freed.

*** set a breakpoint in malloc_error_break to debug

Process 7515 stopped

  • thread #1: tid = 0x3b1be, 0x00007fff8f873212 libsystem_kernel.dylib`__pthread_kill + 10, name = ‘<lldb.driver.main-thread>’, queue = ‘com.apple.main-thread’, stop reason = signal SIGABRT

frame #0: 0x00007fff8f873212 libsystem_kernel.dylib`__pthread_kill + 10

libsystem_kernel.dylib`__pthread_kill + 10:

→ 0x7fff8f873212: jae 0x7fff8f873219 ; __pthread_kill + 17

0x7fff8f873214: jmpq 0x7fff8f8744d4 ; cerror_nocancel

0x7fff8f873219: ret

0x7fff8f87321a: nop

(lldb) bt

  • thread #1: tid = 0x3b1be, 0x00007fff8f873212 libsystem_kernel.dylib`__pthread_kill + 10, name = ‘<lldb.driver.main-thread>’, queue = ‘com.apple.main-thread’, stop reason = signal SIGABRT

  • frame #0: 0x00007fff8f873212 libsystem_kernel.dylib`__pthread_kill + 10

frame #1: 0x00007fff914d9b24 libsystem_c.dylib`pthread_kill + 90

frame #2: 0x00007fff9151df61 libsystem_c.dylib`abort + 143

frame #3: 0x00007fff914f98d5 libsystem_c.dylib`szone_error + 580

frame #4: 0x00007fff914f7628 libsystem_c.dylib`szone_free_definite_size + 1535

frame #5: 0x00007fff914f18c8 libsystem_c.dylib`free + 199

frame #6: 0x000000010160ec52 LLDB`lldb_private::Mangled::GetDemangledName(this=0x000000013833e2f8) const + 322 at Mangled.cpp:214

frame #7: 0x0000000101a38ece LLDB`lldb_private::Symtab::InitNameIndexes(this=0x000000010450a990) + 894 at Symtab.cpp:317

frame #8: 0x0000000101a3da78 LLDB`lldb_private::Symtab::FindAllSymbolsWithNameAndType(this=0x000000010450a990, name=0x00007fff5fbf1c78, symbol_type=eSymbolTypeObjCClass, symbol_indexes=0x00007fff5fbf1330) + 120 at Symtab.cpp:791

frame #9: 0x000000010161a9ab LLDB`lldb_private::Module::FindSymbolsWithNameAndType(this=0x0000000104500b70, name=0x00007fff5fbf1c78, symbol_type=eSymbolTypeObjCClass, sc_list=0x00007fff5fbf17b0) + 443 at Module.cpp:1316

frame #10: 0x00000001016240f5 LLDB`lldb_private::ModuleList::FindSymbolsWithNameAndType(this=0x0000000105800188, name=0x00007fff5fbf1c78, symbol_type=eSymbolTypeObjCClass, sc_list=0x00007fff5fbf17b0, append=false) const + 597 at ModuleList.cpp:528

frame #11: 0x0000000101a96a90 LLDB`lldb_private::ObjCLanguageRuntime::LookupInCompleteClassCache(this=0x000000013227feb0, name=0x00007fff5fbf1c78) + 1456 at ObjCLanguageRuntime.cpp:101

frame #12: 0x0000000101692b83 LLDB`lldb_private::ValueObject::MaybeCalculateCompleteType(this=0x0000000132a334b0) + 755 at ValueObject.cpp:328

frame #13: 0x0000000101692eb0 LLDB`lldb_private::ValueObject::GetClangType(this=0x0000000132a334b0) + 32 at ValueObject.cpp:359

frame #14: 0x0000000101dffae2 LLDB`lldb_private::FormatNavigator<lldb_private::ConstString, lldb_private::TypeFormatImpl>::Get(this=0x000000012f663200, valobj=0x0000000132a334b0, entry=0x00007fff5fbf20c0, use_dynamic=eNoDynamicValues, why=0x00007fff5fbf2114) + 98 at FormatNavigator.h:291

frame #15: 0x0000000101dfc583 LLDB`lldb_private::TypeCategoryImpl::Get(this=0x000000012f663110, valobj=0x0000000132a334b0, entry=0x00007fff5fbf20c0, use_dynamic=eNoDynamicValues, reason=0x00007fff5fbf2114) + 115 at TypeCategory.cpp:48

frame #16: 0x0000000101e1f27f LLDB`lldb_private::TypeCategoryMap::GetFormat(this=0x000000010277e230, valobj=0x0000000132a334b0, use_dynamic=eNoDynamicValues) + 863 at TypeCategoryMap.cpp:196

frame #17: 0x0000000101de6921 LLDB`lldb_private::FormatManager::GetFormat(this=0x000000010277e148, valobj=0x0000000132a334b0, use_dynamic=eNoDynamicValues) + 753 at FormatManager.cpp:447

frame #18: 0x0000000101ddee72 LLDB`lldb_private::DataVisualization::GetFormat(valobj=0x0000000132a334b0, use_dynamic=eNoDynamicValues) + 50 at DataVisualization.cpp:52

frame #19: 0x0000000101691bb1 LLDB`lldb_private::ValueObject::UpdateFormatsIfNeeded(this=0x0000000132a334b0) + 193 at ValueObject.cpp:248

frame #20: 0x000000010169164b LLDB`lldb_private::ValueObject::UpdateValueIfNeeded(this=0x0000000132a334b0, update_format=true) + 75 at ValueObject.cpp:168

frame #21: 0x000000010169aefa LLDB`lldb_private::ValueObject::GetValueAsCString(this=0x0000000132a334b0) + 42 at ValueObject.cpp:1470

frame #22: 0x00000001015cfd2e LLDB`FormatPromptRecurse(format=0x0000000132a31f8c, sc=0x0000000132a31cb0, exe_ctx=0x00007fff5fbf7b78, addr=0x0000000000000000, s=0x00007fff5fbf5670, end=0x00007fff5fbf56b0, valobj=0x0000000000000000) + 21006 at Debugger.cpp:2285

frame #23: 0x00000001015caceb LLDB`FormatPromptRecurse(format=0x0000000132a31f73, sc=0x0000000132a31cb0, exe_ctx=0x00007fff5fbf7b78, addr=0x0000000000000000, s=0x00007fff5fbf7090, end=0x00007fff5fbf70d0, valobj=0x0000000000000000) + 459 at Debugger.cpp:1526

frame #24: 0x00000001015caceb LLDB`FormatPromptRecurse(format=0x0000000132a31f50, sc=0x0000000132a31cb0, exe_ctx=0x00007fff5fbf7b78, addr=0x0000000000000000, s=0x00007fff5fbf7b28, end=0x0000000000000000, valobj=0x0000000000000000) + 459 at Debugger.cpp:1526

frame #25: 0x00000001015caac1 LLDB`lldb_private::Debugger::FormatPrompt(format=0x0000000132a31f50, sc=0x0000000132a31cb0, exe_ctx=0x00007fff5fbf7b78, addr=0x0000000000000000, s=0x00007fff5fbf7b28, valobj=0x0000000000000000) + 641 at Debugger.cpp:2622

frame #26: 0x0000000101afb7ef LLDB`lldb_private::StackFrame::DumpUsingSettingsFormat(this=0x0000000132a31c40, strm=0x00000001034b94e0, frame_marker=0x00007fff5fbf7e71) + 495 at StackFrame.cpp:1294

frame #27: 0x0000000101afca1c LLDB`lldb_private::StackFrame::GetStatus(this=0x0000000132a31c40, strm=0x00000001034b94e0, show_frame_info=true, show_source=false, frame_marker=0x00007fff5fbf7e71) + 108 at StackFrame.cpp:1384

frame #28: 0x0000000101b05641 LLDB`lldb_private::StackFrameList::GetStatus(this=0x000000012f658eb0, strm=0x00000001034b94e0, first_frame=0, num_frames=4294967295, show_frame_info=true, num_frames_with_source=0, selected_frame_marker=0x00000001020d5fd4) + 2929 at StackFrameList.cpp:909

frame #29: 0x0000000101b534be LLDB`lldb_private::thread::GetStatus(this=0x000000010422b620, strm=0x00000001034b94e0, start_frame=0, num_frames=4294967295, num_frames_with_source=0) + 1582 at Thread.cpp:1970

frame #30: 0x000000010157c9de LLDB`CommandObjectThreadBacktrace::DoExecute(this=0x0000000103425690, command=0x00007fff5fbf89a0, result=0x00000001034b94e0) + 190 at CommandObjectThread.cpp:175

frame #31: 0x00000001017f26fb LLDB`lldb_private::CommandObjectParsed::Execute(this=0x0000000103425690, args_string=0x00007fff5fbf9309, result=0x00000001034b94e0) + 715 at CommandObject.cpp:1037

frame #32: 0x00000001017cbbc4 LLDB`lldb_private::CommandInterpreter::HandleCommand(this=0x00000001034112b0, command_line=0x00007fff5fbfafb1, lazy_add_to_history=eLazyBoolCalculate, result=0x00000001034b94e0, override_context=0x0000000000000000, repeat_on_empty_command=true, no_context_switching=true) + 21492 at CommandInterpreter.cpp:1850

frame #33: 0x00000001017f99d8 LLDB`lldb_private::CommandObjectRegexCommand::DoExecute(this=0x00000001034394f0, command=0x00007fff5fbfbe89, result=0x00000001034b94e0) + 2984 at CommandObjectRegexCommand.cpp:89

frame #34: 0x00000001017f2a95 LLDB`lldb_private::CommandObjectRaw::Execute(this=0x00000001034394f0, args_string=0x00007fff5fbfbe89, result=0x00000001034b94e0) + 789 at CommandObject.cpp:1063

frame #35: 0x00000001017cbbc4 LLDB`lldb_private::CommandInterpreter::HandleCommand(this=0x00000001034112b0, command_line=0x000000010425a7b9, lazy_add_to_history=eLazyBoolYes, result=0x00000001034b94e0, override_context=0x0000000000000000, repeat_on_empty_command=true, no_context_switching=false) + 21492 at CommandInterpreter.cpp:1850

frame #36: 0x00000001000d1754 LLDB`lldb::SBCommandInterpreter::HandleCommand(this=0x00007fff5fbfdb20, command_line=0x000000010425a7b9, result=0x00007fff5fbfdb28, add_to_history=true) + 292 at SBCommandInterpreter.cpp:122

frame #37: 0x0000000100008e47 lldb`Driver::HandleIOEvent(this=0x00007fff5fbff9a0, event=0x00007fff5fbfe060) + 183 at Driver.cpp:1171

frame #38: 0x000000010000be68 lldb`Driver::MainLoop(this=0x00007fff5fbff9a0) + 10184 at Driver.cpp:1629

frame #39: 0x000000010000c923 lldb`main(argc=1, argv=0x00007fff5fbffb18, envp=0x00007fff5fbffb28) + 467 at Driver.cpp:1802

frame #40: 0x0000000100001044 lldb`start + 52

This is a known issue. It actually isn't a bug in lldb, but rather a bug in the C++ demangler library on the system. The problem and some potential solutions are discussed in this post in the Apple Developer forums:

The simplest solution is to get your hands on a copy of the libcxxabi.dylib that ships with Mavericks (which does not have this problem) or build your own copy of the LLVM TOT libcxxabi dylib - instructions to do that are also included in the devforms thread.

Jim

This crash is due to the name demangler. We recently inlined the demangling code into LLDB for Xcode builds because the libc++abi.dylib on the system had this crashing bug. If you download and build top of tree LLDB and debug using that and it still crashes, we need to know the mangled name that causing the demangler to crash.

So, if you can go to frame #6 in your example below and type "frame variable" you will see the mangled name that is causing this to crash.

Let us know if top of tree is still crashing and if so, please send us the mangled name that is causing the crash.

Greg