Crashing thread from Core Dump


I’m currently building a solution that parses stack traces from lldb into json, but I’ve run into the issue where I’m not able to find out which thread actually caused the crash itself.
In GDB, the default selected thread seems to be the one that crashed, but in LLDB it always seems like thread 1 is selected.
I had a feeling the python api might export the data I needed, but stop_reason and similar properties didn’t seem to vary between the crashing/non-crashing threads.

Any help would be really appreciated!

// Karl

I am not sure we always know from a core file why things crashed. Is this information found in the ELF core file? It probably isn't. I don't think it is available in mach-o core files either.

LLDB will always select the crashing thread if the thread had a stop reason. Let me know if this isn't happening. What does the output of:

(lldb) thread list

show? It should list all of the threads and their stop reasons, but again, I don't think core files contain the stop reasons for each thread so there is no way the ProcessElfCore plug-in can set the stop reason correctly.

I am unfortunately not getting that behaviour out of lldb 330.0.44.

I’m running a small test file in order to try the behaviour out:

void threadTest(){
int *a = nullptr;
std::cout << *a << std::endl;

int main(){
auto t = std::thread(threadTest);

return 0;

If I then attach lldb to the generated core file, and run thread list I get the following output

(lldb) thread list
Process 0 stopped

  • thread #1: tid = 0x0000, 0x00007fff88cf648a libsystem_kernel.dylib__semwait_signal + 10, stop reason = signal SIGSTOP thread #2: tid = 0x0001, 0x000000010126624b testthreadTest() + 27, stop reason = signal SIGSTOP

mån 20 apr. 2015 kl 19:01 skrev Greg Clayton <>:

So we are pretending every thread stopped due to a SIGSTOP. As I said, you don't know why threads crash in core files as this info isn't stored in the core file.


I realised that was your point after I sent the last email, I think my brain was tunnelling on core dumps a bit too hard. Ended up parsing the CrashReporter log on OS X instead, which worked really well, since the crashing thread information was included in that data with the stack traces.

Thanks for the info about what data is in a core dump. Really helped getting my head to swap ideas.

tis 21 apr. 2015 kl 18:58 skrev Greg Clayton <>: