[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 <gclayton at apple.com>
Date:   Fri Aug 27 21:47:54 2010 +0000

    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 <zturner at google.com> wrote:
> 
> I was going through doing some routine StringRef changes and I ran across this function:
> 
>   std::lock_guard<std::recursive_mutex> 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.