[Lldb-commits] [PATCH] D12968: Fix for lldb-mi crash in Listener code if -exec-abort MI command was invoked without getting process stopped

[Kirill Lapshin via lldb-commits]

KLapshin added a comment.

In http://reviews.llvm.org/D12968#251719, @labath wrote:

> In http://reviews.llvm.org/D12968#251696, @KLapshin wrote:
>
> > Regarding matter of this patch - I just tried to make process stop synchronous, see Process::ResumeSynchronous() - same technique was applied months ago (@ki.stfu).
> >
> > Agreed what crash may be related to freed memory reuse, but not investigated it yet in deep.
>
>
> Fair enough, your patch definitely makes things better. I'm just trying to understand the root cause so we can fix this definitively.
>
> If you look at ResumeSynchronous, you see that the hijacking happens there before we attempt to resume the process (PrivateResume()). This makes it race-free because we grab the events before it gets a chance to generate any. In your case, things are a bit more complicated, since the process is already running and can come to a stop at any moment, and we need to make sure we don't miss those events.
>
> Do you have the ability to run lldb-mi under valgrind or msan? If you can, I'd be interested in taking a look at the output they produce in this case. Or if you have a simple repro case, I can try to do it myself.
>
> pl


@labath,

No, I didn't tried to use valgrind yet, as testcase you can create some Cocoa app in Xcode (actually Empty Form template is enough - just to make sure what app will not ended by itself), then start debug session on iOS device or OSX using lldb-mi (i.e. - via MI) and just do -exec-run, then do -exec-abort while app running - without this patch you will be able to reproduce crash easily. I checked if crash may be reproduced with your race condition patch - yes, reproducible.


Repository:
  rL LLVM

http://reviews.llvm.org/D12968