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 <[email protected]> 
> 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 <[email protected]>:
> 
> > On Apr 18, 2015, at 1:11 PM, Karl Johan Krantz 
> > <[email protected]> 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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to