[llvm-bugs] [Bug 26842] New: LLDB GUI segfault when continuing with the thread frame list expanded

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Mar 4 09:49:27 PST 2016


https://llvm.org/bugs/show_bug.cgi?id=26842

            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 at lists.llvm.org
          Reporter: kknb1056 at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 15986
  --> https://llvm.org/bugs/attachment.cgi?id=15986&action=edit
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
value>, 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160304/a70210b2/attachment.html>


More information about the llvm-bugs mailing list