> On Sep 20, 2018, at 4:16 AM, Zachary Turner wrote:
>
> For the first, I think 99% of the time the bug is not caused by the sequence
> of gdb remote packets. The sequence of gdb remote packets just happens to be
> the means by which the debugger was put into the state in which it failed.
For the first, I think 99% of the time the bug is not caused by the
sequence of gdb remote packets. The sequence of gdb remote packets just
happens to be the means by which the debugger was put into the state in
which it failed. If there is another, stable way of getting the debugger
into the sam
Yes, I think that would be pretty cool. It is along the same lines we've been
talking about with using "ProcessMock", "ThreadMock" etc. plugins. However, I
think you need both. For instance if we bobble a gdb-remote packet, you will
see that in a bad state of one of these higher level state d
There are a couple of problems with using these reproducers in the testsuite.
The first is that we make no commitments that the a future lldb will implement
the "same" session with the same sequence of gdb-remote packet requests. We
often monkey around with lldb's sequences of requests to make
By the way, several weeks / months ago I had an idea for exposing a
debugger object model. That would be one very powerful way to create
reproducers, but it would be a large effort. The idea is that if every
important part of your debugger is represented by some component in a
debugger object mod
I assume that reproducing race conditions is out of scope?
Also, will it be possible to incorporate these reproducers into the test
suite somehow? It would be nice if we could create a tar file similar to a
linkrepro, check in the tar file, and then have a test where you don't have
to write any p
Great, thanks. This means that the lldb-server issues are not in scope for
this feature, right?
On Wed, Sep 19, 2018 at 10:09 AM, Jonas Devlieghere
wrote:
>
>
> On Sep 19, 2018, at 6:49 PM, Leonard Mosescu wrote:
>
> Sounds like a fantastic idea.
>
> How would this work when the behavior of the
> On Sep 19, 2018, at 6:49 PM, Leonard Mosescu wrote:
>
> Sounds like a fantastic idea.
>
> How would this work when the behavior of the debugee process is
> non-deterministic?
All the communication between the debugger and the inferior goes through the
GDB remote protocol. Because we captu
Sounds like a fantastic idea.
How would this work when the behavior of the debugee process is
non-deterministic?
On Wed, Sep 19, 2018 at 6:50 AM, Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> We all know how hard it can be to reproduce an issue or crash in L
Hi everyone,
We all know how hard it can be to reproduce an issue or crash in LLDB. There
are a lot of moving parts and subtle differences can easily add up. We want to
make this easier by generating reproducers in LLDB, similar to what clang does
today.
The core idea is as follows: during normal
10 matches
Mail list logo
