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