When process exits, and SBProcess.Continue() is executed, timeout occurs (5secs). Instead error message "Process is not alive" is returned. Added test for this message.
Fix of breakpoint case sensitivity test on Linux.
Honsik on Feb 25 2016, 8:01 PM.Authored by
It's okay to short-circuit this here, but why was PrivateResume not returning an error when the process was not alive. That error should have gotten propagated to the caller, obviating the need for this short-circuit.
I tried to put this check in PrivateResume, but its not that simple because of the public run lock that is acquired in Resume and ResumeSynchronous. I am not that sure if it is safe to always unclock the lock inside PrivateResume.
It doesn't look like Process::PrivateResume() returns an error if the process is alive unless WillResume() returns an error, which is up to the individual process implementation. So maybe the short circuit needs to happen there. This isn't really my area though so I'll defer to Jim on this review.
I agree with Zachary, it would be better to put it in PrivateResume before the call to WillResume. Having this happen in Process::PrivateResume after taking the run lock is okay, that works correctly on OS X.
OTOH, the error reporting isn't correct there:
<lldb.SBError; proxy of <Swig Object of type 'lldb::SBError *' at 0x10b9e7c00> >
error: Resume timed out.
So this definitely needs fixing generically...
Process::WillResume only gets called in one place (Process::PrivateResume) so it is fine to just put the check there before calling WillResume. When we have generic bits of work we want to do before or after a plugin method X we often make a virtual "DoX" and have that be the plugin method, and then X is not virtual and does the generic work. But that seems overkill in this case, we just want to make sure the process is alive before calling into the plugins.
OK I have modified the PrivateResume to add the check and release the public running lock.
The "Resume timed out" is caused by waiting for debugging thread events, but they won't ever come, because process is already dead.
I don't think you can manipulate the public run lock in PrivateResume like this. PrivateResume gets run in a bunch of places (like calling functions) that are way below the level the public run lock. You probably need to catch errors from PrivateResume in Resume and release the lock there.
That's a little ugly, but it is good to have PrivateResume return an accurate error, so I think putting the check there is right.