Solved

Are reverse operations re-entrant when interrupted?

  • 26 April 2021
  • 2 replies
  • 39 views
Bruce
Rank
Badge +1
  • Bruce
  • Community Manager
  • 20 replies

If I run a reverse operation such as reverse-continue then interrupt it, I will find myself at some point in the recording earlier than I was previously at, but later than the earliest I might have ended up.  So far, so expected.

If I then repeat the command, is UDB guaranteed to stop at the same point it would have if the original command was not interrupted (because of a breakpoint say), or might it skip that instance and stop at some earlier point in the recording?

Put another way, does repeating a reverse command carry on in a human sense, or could some of the search space in the recording be missed? Or do I need to go back to the point where I was before and start the operation all over again?

icon

Best answer by tobyld 26 April 2021, 17:00

View original

2 replies

T

Yes, for a reverse-continue you should always end up at the same point you would have stopped if the original reverse-continue was not interrupted.

For reverse-step I think this is also true, unless the interrupt leaves you in a different thread. Reverse operations other than reverse-continue (and reverse-stepi currently) stay within the same thread, but the interrupt may leave you in a different thread, meaning that repeating the same operation will search inside a different thread.

For other commands repeating the same command often won’t leave you at the same point you would have stopped, because their behavior depends on where they start. For example the behavior of reverse-finish and reverse-next depends on which function you are in. For another reverse-finish or reverse-next to do the same thing, the interrupt would have to leave you in the same function call as you were originally in.

Bruce
Rank
Badge +1

Thanks @tobyld 

Makes sense about rf and rn, but at least they are usually relatively short-running so losing a lot of the search time will less often be an issue (and will less often be interrupted!)

Reply