[Lldb-commits] [PATCH] Fix handling of hijacked events in synchronous mode

[jingham at apple.com]

> On May 15, 2015, at 10:08 AM, Ilia K <ki.stfu at gmail.com> wrote:
> 
> @jingham wrote:
> 
>> This is not going to be handled by the your "CreateProcessEventStateChanged" since that has no way of knowing whether the event you are emulating was interrupted.  You also need to know whether the event was a stop & restart, which you don't know.
> 
> 
> Agreed. I missed that.
> 
>> I like it more than "generate random stop event" since it says exactly what you are doing, you are choosing to rebroadcast the last stop.
> 
> 
> Yes, it's better, but I'm not sure it's a good decision. In addition, where you want to store the last stop event?
> 
>> An even more explicit way of doing this (though it would require a little side-bookkeeping that we don't currently do) would be SBProcess::GetStopEventForStopID(uint32_t stop_id).  That might actually be more generally useful, though of course if it wasn't the current stop id, you wouldn't currently be able to reconstruct thread states and the like.  But one of our long-term goals for lldb is to be able to store and replay "historical" stop events, with some API to say what you wanted to gather at these historical points.  So it would fit in with that direction.
> 
> 
> Sounds good for me. I'll try to do it.
> 
>> What if there is a Listener fetching events, but then for some reason somebody beneath that Listener switches to sync mode, does some stuff that stops & starts the target, and then switches to async mode on the way out.  The agent which is fetching events is going to see some stopped event with no corresponding running event.  Depending on what the code using async does it could even see a bunch of these, some while the sync code is still working.  How is it going to understand that?
> 
> 
> Why it doesn't get corresponding running event?

Currently that gets swallowed when in sync mode as was intended (and as does the stop event in the normal course of things.)  

> 
>> Depending on what the code using async does it could even see a bunch of these, some while the sync code is still working.
> 
> 
> How? The stop event can be sent only when command was executed. It will not be sent while we are waiting when the command will be finished.

In your case you only run one command, but what if the code that switched to sync mode under the covers ran a bunch of commands.  In your original patch the stopped would get sent when the first command that runs the target completes, not when the entire sync session completes.

Jim


> 
> 
> http://reviews.llvm.org/D9371
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
>