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 <gclay...@apple.com>:
> 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.
>
> Greg
>
> > On Apr 21, 2015, at 12:51 AM, Karl Johan Krantz <
> karl.johan.kra...@gmail.com> wrote:
> >
> > 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;
> > std::abort();
> > }
> >
> > int main(){
> > auto t = std::thread(threadTest);
> > t.join();
> >
> > 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 test`threadTest() + 27,
> stop reason = signal SIGSTOP
> >
> > mån 20 apr. 2015 kl 19:01 skrev Greg Clayton <gclay...@apple.com>:
> >
> > > On Apr 18, 2015, at 1:11 PM, Karl Johan Krantz <
> karl.johan.kra...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > 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.
> >
> > 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.
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
