<div dir="ltr">Thanks for the info.<div><br></div><div>This is not theoretical.  I'm trying to get TestBreakAfterJoin to pass on Windows.  Step 1 was to convert it use <thread> instead of <pthreads.h>.  Step 2 was to fix some minor issues in TargetThreadWindows.</div><div><br></div><div>But now the inferior deadlocks because the one thread that's not suspended is waiting on the ones that are.  Once the ThreadPlanStepOverBreakpoint plan is popped, the current plan is ThreadPlanBase, which, as far as I can tell, does nothing to resume suspended threads.<br><br>I'll compare this to what happens on another platform to see if there should be some other thread plan in use.<br></div><div><br></div><div>Adrian.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 4:50 PM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When stepping over a breakpoint, the ThreadPlanStepOverBreakpoint gets pushed, handles the single instruction step - during which it does suspend the other threads - then it gets popped.  When you next resume, whatever plan was handling the stepping before the breakpoint was hit will resume with whatever policy for running other threads it was using.<br>
<br>
So it's up to the plan that was on the stack before the "StepOverBreakpoint" was pushed to decide this.  Most of the more complex plans (like step-over/step-into) try to keep the other threads from running if possible (unless the user instructed otherwise) but they also will let all the threads run if there's something going on that might deadlock.  For instance, if you are doing "next" and we step through straight-line instructions in a function, we will only run the one thread you are stepping in (by default, you can control this with options to the "thread step-over" command.   But if we step into a function, we set a breakpoint on the return address and then run with all threads resumed because stepping out of a function could run arbitrary code.<br>
<br>
Anyway, was this a theoretical question, or do you have some instance where you are actually seeing a deadlock?<br>
<br>
Jim<br>
<div><div class="h5"><br>
<br>
> On May 29, 2015, at 1:59 PM, Adrian McCarthy <<a href="mailto:amccarth@google.com">amccarth@google.com</a>> wrote:<br>
><br>
> [I'm trying to make TestBreakAfterJoin work on Windows.]<br>
><br>
> I'm unclear how continuing from a breakpoint in a multi-threaded inferior is supposed to work.<br>
><br>
> A breakpoint is set, and the inferior runs until one of its threads hits the breakpoint.  The user then selects continue.<br>
><br>
> The thread that had hit the breakpoint has a thread plan type of ThreadPlanStepOverBreakpoint, which causes all of the other threads to be set to state eStateSuspended.  The thread that had hit the breakpoint then steps beyond the breakpoint, and the breakpoint is restored.  The thread is then resumed again.<br>
><br>
> But the other threads are all still suspended, causing the inferior to deadlock.<br>
><br>
> The question is:  Where should the other threads have their resume states set back to a running state?<br>
><br>
> Adrian<br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div>