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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to