> > all ReportRegisterState does is pretty print its register context
If I invalidate the registers (specifically up to 67) after reading them then the problem goes away. If I understand correctly, the registers should be invalidated after every new process_stop_id right? I find it strange that the StopInfoThreadPlan would be handled in a different process_stop_id than the one in which the ThreadPlanCallFunction is popped. The comments on StopInfo::ShouldStop says: > The ShouldStop method should not do anything that might run code. Could this have anything to do with it? I tried caching the ShouldStop value in PerformAction, but the problem still happens. And anyway, this code only does anything at all if the Expression log is on > and in verbose mode. Did you have that log on? > Yeah, the error only happens with logging on. On Thu, Mar 26, 2015 at 3:06 PM, Jim Ingham <[email protected]> wrote: > I don't understand how calling ReportRegisterState when the takedown had > already been done could cause the error you report - though without more > details about what you are doing it's hard to say for sure. > > After all, within ShouldStop the m_thread in the ThreadPlan must still be > valid, and all ReportRegisterState does is pretty print its register > context. That also should still be good, if it is not, something is wrong > at a deeper level. > > And anyway, this code only does anything at all if the Expression log is > on and in verbose mode. Did you have that log on? > > I don't have a strong objection to this change, after all this is just a > log output. OTOH I worry that it is just papering over some real problem, > so it would be better to figure out what that is. > > > http://reviews.llvm.org/D8643 > > EMAIL PREFERENCES > http://reviews.llvm.org/settings/panel/emailpreferences/ > > >
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
