[Lldb-commits] [lldb] r316740 - Fix a use-after-free in lldb-server

[Zachary Turner via lldb-commits]

Well, at least the good news is this kind of bug *should* have been caught
had we been using a conformant standard library implementation.

Have you ever tried running the test suite with an ASAN instrumented build
of LLDB?  We really should have one ASAN bot for every supported
configuration.

On Tue, Oct 31, 2017 at 8:48 AM Pavel Labath <labath at google.com> wrote:

> libstdc++-4.8
>
> I think the newest versions have a conformant implementation, but I
> don't know the full details (I know it was a complicated change
> because of the need to maintain binary compatibility).
>
> Our android tests are now runinng lldb-server built with libc++ (which
> is how I found the bug). Eventually (= probably not this year) I may
> switch the host lldb as well.
>
> On 31 October 2017 at 15:41, Zachary Turner <zturner at google.com> wrote:
> >
> >
> > On Tue, Oct 31, 2017 at 8:20 AM Pavel Labath <labath at google.com> wrote:
> >>
> >> On 31 October 2017 at 15:12, Zachary Turner via lldb-commits
> >> <lldb-commits at lists.llvm.org> wrote:
> >> > The takeaway from this example is nothing we don't already know.  We
> >> > need
> >> > better test coverage.
> >> Actually, this was caught by a test (pretty much all of them), but
> >> only when building with libc++, as the code was "safe" with libstdc++
> >> due to the copy-on-write implementation of std::string (the temporary
> >> object shared storage with the longer-lived string it was copied
> >> from).
> >
> >
> > What version of libstdc++?  AFAIK copy-on-write std::string is no longer
> > conformant in C++11.
> >
> > If this was really being masked due to a CoW string implementation, we
> need
> > to make absolutely sure we are running tests on a bot with a conformant
> > standard library.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171031/e2ba784f/attachment.html>