Re: [lldb-dev] LLDB hang loading Linux core files from live processes (Bug 26322)

[Howard Hellyer via lldb-dev]

> You want to figure out which one the accurate signal and use that. 
> Doesn't matter how you do this, but this will be up to the 
> ProcessELFCore or ThreadELFCore classes.

I'm going to do a little more research (books and google) to see if I can 
get an answer on this one. I'm actually having trouble finding core files 
(at least in my own collection) where threads have different signals in 
info.si_signo in PRSTATUS. For the ones I've checked that crashed or 
received a signal all the threads have the same value in info.si_signo. 
Typically just one thread (the thread that triggered or received the 
signal) has a SIGINFO note for the thread that actually received the 
signal. (My collection of cores is a bit random so that's not a 
comprehensive survey by any means.)

I'm getting the impression that the value in PRSTATUS may be for the whole 
process with any thread that actually received a signal having a SIGINFO 
note containing that information but I'm not totally sure either way yet. 
I haven't found anything that documents that behaviour yet. (If anyone 
knows of a good reference please let me know!) It would explain why all 
the threads in a core created by gcore have a SIGINFO note as each one 
will be stopped in turn. It would also mean that for the non-gcore created 
cores I've got (from crashes and kills) only one thread would have a 
non-zero signal which sounds correct. Currently for those core files 
running "thread list" shows all threads as having stopped on the same 
signal with only one thread in a position where that signal makes sense. 
Switching to not use info.si_signo is a slightly bigger change though!

> > - Never allow a threads signal number to be 0 when it comes form 
> an elf core dump. (This is probably as much of a band aid as the 
> first solution.)
> 
> Threads should be able to have no signal. If you have 10 threads and
> thread 6 crashes with SIGABRT, but all other threads were just 
> running, I would expect all threads except for thread 6 to have 0 
> signal values, or no stop reason. If you end up with 10 threads and 
> all have no signal information, I would say that you can just give 
> the first thread a SIGSTOP to be safe.

I checked this with one of the gcore files by just setting the first 
threads signal and leaving the others to pick up 0 as they used to. That 
works.

Putting in a check that makes sure that at least one thread that has some 
kind of signal seems reasonable. I'll add that as a fallback sanity check.

> The suggested can be done in a cleaner way: Have ProcessELFCore and 
> ProcessMachCore override "Error Process::WillResume()" just return an 
error:
> 
> Error ProcessELFCore::WillResume() 
> {
> return Error("can't resume a process in a core file");
> }

I think that's called too late. It's not called until the decision has 
been made to resume the process. Also the base implementation already 
returns an error and I don't think either ProcessElfCore or 
ProcessMachCore override it.

> So I think the correct fix is all three of the above.

I think it's close and discussing the problem is actually helping a lot, 
thanks for the help. I'll grab the bug and put up a patch - hopefully 
tomorrow.

Thanks,

Howard Hellyer 
IBM Runtime Technologies, IBM Systems 



Greg Clayton  wrote on 11/11/2016 18:07:03:

> From: Greg Clayton 
> To: Howard Hellyer/UK/IBM@IBMGB
> Cc: Jim Ingham , lldb-dev@lists.llvm.org
> Date: 11/11/2016 18:07
> Subject: Re: [lldb-dev] LLDB hang loading Linux core files from live
> processes (Bug 26322)
> 
> I think both are valid fixes. Threads in core files can have a non-
> zero signal. See comments below.
> 
> > On Nov 11, 2016, at 5:36 AM, Howard Hellyer via lldb-dev  d...@lists.llvm.org> wrote:
> > 
> > Hi Jim 
> > 
> > I was afraid someone would say that but I've done some digging and
> found a difference in the core files I get generated by gcore to 
> those generated by a crash or abort. 
> > 
> > Most of the core files have one SIGINFO structure in the core, I 
> think it belongs to the preceding thread (the one that caught the 
signal). 
> > In the core files generated by gcore all of the threads have a 
> SIGINFO structure following their PRSTATUS structure. In the non-
> gcore files the value of info.si_signo in the PRSTATUS structure is 
> a signal number. In the gcore file this is actually 0 but the 
> SIGINFO structure following PRSTATUS has an si_signo value of 19. 
> > 
> > Looking at it with eu-readelf shows: 
> > 
> >   CORE 336  PRSTATUS 
> > info.si_signo: 0, info.si_code: 0, info.si_errno: 0, cursig: 0 
> > sigpend: <> 
> > sighold: <> 
> > ... lots of registsers... 
> >   CORE 128  SIGINFO 
> > si_signo: 19, si_errno: 0, si_code: 0 
> > sender PID: 0, sender UID: 0 
> > 
> > I think gcore is being clever. It's including the "real" signal 
> number the running thread had received at the time the core was 
> taken (info.si_signo is 0) but also the sig

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Jim Ingham via lldb-dev]

> On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I was going through doing some routine StringRef changes and I ran across 
> this function:
> 
>   std::lock_guard guard(m_mutex);
>   assert(GetStackID() ==
>  prev_frame.GetStackID()); // TODO: remove this after some testing
>   m_variable_list_sp = prev_frame.m_variable_list_sp;
>   
> m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
>   if (!m_disassembly.GetString().empty()) {
> m_disassembly.Clear();
> m_disassembly.GetString().swap(m_disassembly.GetString());
>   }
> 
> Either I'm crazy or that bolded line is a bug.  Is it supposed to be 
> prev_frame.m_disassembly.GetString()?
> 
> What would the implications of this bug be?  i.e. how can we write a test for 
> this?
> 
> Also, as a matter of curiosity, why is it swapping?  That means it's 
> modifying the input frame, when it seems like it really should just be 
> modifying the current frame.

What lldb does is store the stack frame list it calculated from a previous 
stop, and copy as much as is relevant into the new stack frame when it stops, 
which will then become the stack frame list that gets used.  So this is a 
transfer of information from the older stop's stack frame to the new one.  Thus 
the swap.

To be clear, current here means "the stack frame we are calculating from this 
stop" and previous here means "the stack frame from the last stop".  That's 
confusing because previous & next also get used for up and down the current 
stack frame list.  That's why I always try to use "younger" and "older" for 
ordering in one stack (that and it makes the ordering unambiguous.)

So while this is definitely a bug, this is just going to keep the frames in the 
newly calculated stack frame list from taking advantage of any disassembly that 
was done on frames from the previous stop.  Since this will get created on 
demand if left empty, it should have no behavioral effect.  To test this you 
would have to count the number of times you disassembled the code for a given 
frame.  If this were working properly, you'd only do it once for the time that 
frame lived on the stack.  With this bug you will do it every time you stop and 
ask for disassembly for this frame.

Jim


> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Jason Molenda via lldb-dev]

Looks incorrect to me.  It was introduced with this change.  Adding Greg.


Author: Greg Clayton 
Date:   Fri Aug 27 21:47:54 2010 +

Made it so we update the current frames from the previous frames by doing 
STL
swaps on the variable list, value object list, and disassembly. This avoids
us having to try and update frame indexes and other things that were getting
out of sync.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112301 
91177308-0d34-0410-b5e6-96231b3b80d8



> On Nov 13, 2016, at 4:48 PM, Zachary Turner  wrote:
> 
> I was going through doing some routine StringRef changes and I ran across 
> this function:
> 
>   std::lock_guard guard(m_mutex);
>   assert(GetStackID() ==
>  prev_frame.GetStackID()); // TODO: remove this after some testing
>   m_variable_list_sp = prev_frame.m_variable_list_sp;
>   
> m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
>   if (!m_disassembly.GetString().empty()) {
> m_disassembly.Clear();
> m_disassembly.GetString().swap(m_disassembly.GetString());
>   }
> 
> Either I'm crazy or that bolded line is a bug.  Is it supposed to be 
> prev_frame.m_disassembly.GetString()?
> 
> What would the implications of this bug be?  i.e. how can we write a test for 
> this?
> 
> Also, as a matter of curiosity, why is it swapping?  That means it's 
> modifying the input frame, when it seems like it really should just be 
> modifying the current frame.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Zachary Turner via lldb-dev]

If the swap is correct, then wouldn't we also need to swap the variable
list?

On Mon, Nov 14, 2016 at 10:58 AM Jim Ingham  wrote:

>
> > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I was going through doing some routine StringRef changes and I ran
> across this function:
> >
> >   std::lock_guard guard(m_mutex);
> >   assert(GetStackID() ==
> >  prev_frame.GetStackID()); // TODO: remove this after some
> testing
> >   m_variable_list_sp = prev_frame.m_variable_list_sp;
> >
>  m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
> >   if (!m_disassembly.GetString().empty()) {
> > m_disassembly.Clear();
> > m_disassembly.GetString().swap(m_disassembly.GetString());
> >   }
> >
> > Either I'm crazy or that bolded line is a bug.  Is it supposed to be
> prev_frame.m_disassembly.GetString()?
> >
> > What would the implications of this bug be?  i.e. how can we write a
> test for this?
> >
> > Also, as a matter of curiosity, why is it swapping?  That means it's
> modifying the input frame, when it seems like it really should just be
> modifying the current frame.
>
> What lldb does is store the stack frame list it calculated from a previous
> stop, and copy as much as is relevant into the new stack frame when it
> stops, which will then become the stack frame list that gets used.  So this
> is a transfer of information from the older stop's stack frame to the new
> one.  Thus the swap.
>
> To be clear, current here means "the stack frame we are calculating from
> this stop" and previous here means "the stack frame from the last stop".
> That's confusing because previous & next also get used for up and down the
> current stack frame list.  That's why I always try to use "younger" and
> "older" for ordering in one stack (that and it makes the ordering
> unambiguous.)
>
> So while this is definitely a bug, this is just going to keep the frames
> in the newly calculated stack frame list from taking advantage of any
> disassembly that was done on frames from the previous stop.  Since this
> will get created on demand if left empty, it should have no behavioral
> effect.  To test this you would have to count the number of times you
> disassembled the code for a given frame.  If this were working properly,
> you'd only do it once for the time that frame lived on the stack.  With
> this bug you will do it every time you stop and ask for disassembly for
> this frame.
>
> Jim
>
>
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Jason Molenda via lldb-dev]

For reference, the original code that Greg wrote in r112301 was

+if (!m_disassembly.GetString().empty())
+m_disassembly.GetString().swap (m_disassembly.GetString());




> On Nov 14, 2016, at 1:44 PM, Zachary Turner  wrote:
> 
> If the swap is correct, then wouldn't we also need to swap the variable list?
> 
> On Mon, Nov 14, 2016 at 10:58 AM Jim Ingham  wrote:
> 
> > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > I was going through doing some routine StringRef changes and I ran across 
> > this function:
> >
> >   std::lock_guard guard(m_mutex);
> >   assert(GetStackID() ==
> >  prev_frame.GetStackID()); // TODO: remove this after some testing
> >   m_variable_list_sp = prev_frame.m_variable_list_sp;
> >   
> > m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
> >   if (!m_disassembly.GetString().empty()) {
> > m_disassembly.Clear();
> > m_disassembly.GetString().swap(m_disassembly.GetString());
> >   }
> >
> > Either I'm crazy or that bolded line is a bug.  Is it supposed to be 
> > prev_frame.m_disassembly.GetString()?
> >
> > What would the implications of this bug be?  i.e. how can we write a test 
> > for this?
> >
> > Also, as a matter of curiosity, why is it swapping?  That means it's 
> > modifying the input frame, when it seems like it really should just be 
> > modifying the current frame.
> 
> What lldb does is store the stack frame list it calculated from a previous 
> stop, and copy as much as is relevant into the new stack frame when it stops, 
> which will then become the stack frame list that gets used.  So this is a 
> transfer of information from the older stop's stack frame to the new one.  
> Thus the swap.
> 
> To be clear, current here means "the stack frame we are calculating from this 
> stop" and previous here means "the stack frame from the last stop".  That's 
> confusing because previous & next also get used for up and down the current 
> stack frame list.  That's why I always try to use "younger" and "older" for 
> ordering in one stack (that and it makes the ordering unambiguous.)
> 
> So while this is definitely a bug, this is just going to keep the frames in 
> the newly calculated stack frame list from taking advantage of any 
> disassembly that was done on frames from the previous stop.  Since this will 
> get created on demand if left empty, it should have no behavioral effect.  To 
> test this you would have to count the number of times you disassembled the 
> code for a given frame.  If this were working properly, you'd only do it once 
> for the time that frame lived on the stack.  With this bug you will do it 
> every time you stop and ask for disassembly for this frame.
> 
> Jim
> 
> 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Zachary Turner via lldb-dev]

Yea, sorry, some of my local changes were mixed in there.  But the original
code that you posted above still has the same issue.

On Mon, Nov 14, 2016 at 1:52 PM Jason Molenda  wrote:

> For reference, the original code that Greg wrote in r112301 was
>
> +if (!m_disassembly.GetString().empty())
> +m_disassembly.GetString().swap (m_disassembly.GetString());
>
>
>
>
> > On Nov 14, 2016, at 1:44 PM, Zachary Turner  wrote:
> >
> > If the swap is correct, then wouldn't we also need to swap the variable
> list?
> >
> > On Mon, Nov 14, 2016 at 10:58 AM Jim Ingham  wrote:
> >
> > > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > I was going through doing some routine StringRef changes and I ran
> across this function:
> > >
> > >   std::lock_guard guard(m_mutex);
> > >   assert(GetStackID() ==
> > >  prev_frame.GetStackID()); // TODO: remove this after some
> testing
> > >   m_variable_list_sp = prev_frame.m_variable_list_sp;
> > >
>  m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
> > >   if (!m_disassembly.GetString().empty()) {
> > > m_disassembly.Clear();
> > > m_disassembly.GetString().swap(m_disassembly.GetString());
> > >   }
> > >
> > > Either I'm crazy or that bolded line is a bug.  Is it supposed to be
> prev_frame.m_disassembly.GetString()?
> > >
> > > What would the implications of this bug be?  i.e. how can we write a
> test for this?
> > >
> > > Also, as a matter of curiosity, why is it swapping?  That means it's
> modifying the input frame, when it seems like it really should just be
> modifying the current frame.
> >
> > What lldb does is store the stack frame list it calculated from a
> previous stop, and copy as much as is relevant into the new stack frame
> when it stops, which will then become the stack frame list that gets used.
> So this is a transfer of information from the older stop's stack frame to
> the new one.  Thus the swap.
> >
> > To be clear, current here means "the stack frame we are calculating from
> this stop" and previous here means "the stack frame from the last stop".
> That's confusing because previous & next also get used for up and down the
> current stack frame list.  That's why I always try to use "younger" and
> "older" for ordering in one stack (that and it makes the ordering
> unambiguous.)
> >
> > So while this is definitely a bug, this is just going to keep the frames
> in the newly calculated stack frame list from taking advantage of any
> disassembly that was done on frames from the previous stop.  Since this
> will get created on demand if left empty, it should have no behavioral
> effect.  To test this you would have to count the number of times you
> disassembled the code for a given frame.  If this were working properly,
> you'd only do it once for the time that frame lived on the stack.  With
> this bug you will do it every time you stop and ask for disassembly for
> this frame.
> >
> > Jim
> >
> >
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

[Jim Ingham via lldb-dev]

> On Nov 14, 2016, at 1:44 PM, Zachary Turner  wrote:
> 
> If the swap is correct, then wouldn't we also need to swap the variable list?

That would make things more symmetrical, though all your doing is skipping the 
shared pointer ref count manipulations so it isn't terribly important.

Jim


> 
> On Mon, Nov 14, 2016 at 10:58 AM Jim Ingham  wrote:
> 
> > On Nov 13, 2016, at 4:48 PM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > I was going through doing some routine StringRef changes and I ran across 
> > this function:
> >
> >   std::lock_guard guard(m_mutex);
> >   assert(GetStackID() ==
> >  prev_frame.GetStackID()); // TODO: remove this after some testing
> >   m_variable_list_sp = prev_frame.m_variable_list_sp;
> >   
> > m_variable_list_value_objects.Swap(prev_frame.m_variable_list_value_objects);
> >   if (!m_disassembly.GetString().empty()) {
> > m_disassembly.Clear();
> > m_disassembly.GetString().swap(m_disassembly.GetString());
> >   }
> >
> > Either I'm crazy or that bolded line is a bug.  Is it supposed to be 
> > prev_frame.m_disassembly.GetString()?
> >
> > What would the implications of this bug be?  i.e. how can we write a test 
> > for this?
> >
> > Also, as a matter of curiosity, why is it swapping?  That means it's 
> > modifying the input frame, when it seems like it really should just be 
> > modifying the current frame.
> 
> What lldb does is store the stack frame list it calculated from a previous 
> stop, and copy as much as is relevant into the new stack frame when it stops, 
> which will then become the stack frame list that gets used.  So this is a 
> transfer of information from the older stop's stack frame to the new one.  
> Thus the swap.
> 
> To be clear, current here means "the stack frame we are calculating from this 
> stop" and previous here means "the stack frame from the last stop".  That's 
> confusing because previous & next also get used for up and down the current 
> stack frame list.  That's why I always try to use "younger" and "older" for 
> ordering in one stack (that and it makes the ordering unambiguous.)
> 
> So while this is definitely a bug, this is just going to keep the frames in 
> the newly calculated stack frame list from taking advantage of any 
> disassembly that was done on frames from the previous stop.  Since this will 
> get created on demand if left empty, it should have no behavioral effect.  To 
> test this you would have to count the number of times you disassembled the 
> code for a given frame.  If this were working properly, you'd only do it once 
> for the time that frame lived on the stack.  With this bug you will do it 
> every time you stop and ask for disassembly for this frame.
> 
> Jim
> 
> 
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7

[Rudy Pons via lldb-dev]

Hello,

I had a similar crash, and submitted a patch commited in rL285843

You could try to build afte this version from source, or wait for an
updated build.


On Sun, Nov 13, 2016 at 5:31 PM, Eli Zaretskii via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I installed a 32-bit Windows build of LLVM 4.0.0 from this page:
>
>   http://llvm.org/builds/
>
> where it is identified as "based on SVN r284979 (24 October 2016)".
> (I actually wanted only LLDB, but there doesn't seem to be a separate
> installer for that.)  The machine where I installed it runs the 64-bit
> Windows 7 OS.  The only setting I changed during the installation was
> the installation directory: instead of the default under "C:\Program
> Files (x86)" I've installed it under d:\usr.
>
> The installation went fine.  After installing, I found that I needed
> Python 3.5.x, so I installed this:
>
>   https://www.python.org/ftp/python/3.5.2/python-3.5.2.exe
>
> The installed Python works correctly.
>
> After all this, lldb crashes when it attempts to start a debuggee.
> Specifically, whenever I say "process launch -s" inside the debugger,
> it crashes.  (The information about the crash available in the Windows
> Event Viewer is at the end of this message.)  The same happens if I
> type "lldb PROGRAM" from the Windows cmd.exe prompt.  Until I try to
> launch the debuggee, lldb works: I can type the various commands,
> including "help" and they produce expected results.
>
> The crash is inside liblldb.dll, and the exception code seems to
> indicate that some C runtime library function is called with incorrect
> or invalid arguments.
>
> Other programs that came with the installation -- clang, llvm-ar,
> llvm-objdump -- seem to work fine and produce the expected results.
> In particular, I compiled a small C program with clang.
>
> So the installation seems to work fine, and only lldb crashes.
>
> What am I doing wrong?
>
> Thanks in advance for any help.
>
> Here's the info from the Event Viewer:
>
> Log Name:  Application
> Source:Application Error
> Date:  13/11/2016 13:24:58
> Event ID:  1000
> Task Category: (100)
> Level: Error
> Keywords:  Classic
> User:  N/A
> Computer:  C1050100036.ness.com
> Description:
> Faulting application name: lldb.exe, version: 4.0.0.0, time stamp:
> 0x580fd053
> Faulting module name: liblldb.dll, version: 4.0.0.0, time stamp: 0x580fd046
> Exception code: 0xc417
> Fault offset: 0x027295d2
> Faulting process id: 0x1564
> Faulting application start time: 0x01d23da09025cbd5
> Faulting application path: D:\usr\LLVM\bin\lldb.exe
> Faulting module path: D:\usr\LLVM\bin\liblldb.dll
> Report Id: cef982bb-a993-11e6-a608-001b10002aec
> Event Xml:
> http://schemas.microsoft.com/win/2004/08/events/event";>
>   
> 
> 1000
> 2
> 100
> 0x80
> 
> 121846
> Application
> C1050100036.ness.com
> 
>   
>   
> lldb.exe
> 4.0.0.0
> 580fd053
> liblldb.dll
> 4.0.0.0
> 580fd046
> c417
> 027295d2
> 1564
> 01d23da09025cbd5
> D:\usr\LLVM\bin\lldb.exe
> D:\usr\LLVM\bin\liblldb.dll
> cef982bb-a993-11e6-a608-001b10002aec
>   
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev