Bug ID 26842
Summary LLDB GUI segfault when continuing with the thread frame list expanded
Product lldb
Version 3.8
Hardware Macintosh
OS MacOS X
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter kknb1056@gmail.com
CC llvm-bugs@lists.llvm.org
Classification Unclassified
Created attachment 15986 [details]
Example backtrace of a crash, plus the proposed patch to fix
I have a fix for this, but I wasn't sure if the correct etiquette is to file a
bug report before posting a patch to lldb-commits?
If the frame stack changes while the list is expanded in the Threads window,
there will be a high likelihood of a segfault. For example, expanding the list
and then "continue" to another breakpoint where the list is different. I can
give a specific program and instructions if required but any program should do
it. An example stack trace is attached.
This is with the version of lldb shipped with XCode 7.2.1 (lldb-340.4.119.1) as
well as the current head (as at 04/Mar/16).
The problem is that, when creating the updated list it is done with
vector<TreeItem>::resize( <new size>, <new value> );
(via calls to TreeItem::Resize in IOHandler.cpp lines 3312 and 3422). The
intention of the code is to fill the m_children vector with copies of <new
>, but std::vector::resize only uses the <new value> for new values -
items already in the vector are left untouched. Hence all items up to the old
size will have invalid pointers to parent etcetera, and subsequent Draw calls
will screw up.
I propose to insert a call to TreeItem::ClearChildren() immediately before the
TreeItem::Resize(..) calls so that all children correctly take on the new
value.
A patch is attached, but I could only append one file so it's after the
backtrace.