Protect against deadlocks in stack walk API

Summary:
This is just adding some extra defense to the stack walk API. alexmalyshev asked "What happens if a second sampling thread appears and sends another SIGUSR1?" It's actually the callers responsibility to protect this with a lock (which we rely on either the GIL or the FreeThreadedJITEntrypointGuard to do so). But there's an additional concern about if someone sent our walking thread a signal while we were trying to walk the stack.

In that case the walking thread that sent us the signal could depend upon a resource owned by the thread that we are trying to walk. That'd result in a deadlock. So now the sampled thread will give up if the sampling thread fails to walk it in a reasonable amount of time.

Reviewed By: alexmalyshev

Differential Revision: D116388968

fbshipit-source-id: 8fa581c5fb57081c3f0bad3cdd74d25f4900fa83

Author: DinoV

cinderx/Jit/frame.cpp

@@ -160,7 +160,12 @@ const void** getIPStackAddr(_PyInterpreterFrame* frame, int) {
 
   FreeThreadedJITEntrypointGuard guard;
   StackWalk walker;
-  walker.walk(owner, visit);
+  if (walker.walk(owner, visit) != WalkResult::Completed) {
+    // A walk that did not finish leaves nothing worth keeping. It either never
+    // started, or the owner stopped waiting for us part way through - and an
+    // address out of a stack that has resumed is not one to hand back.
+    return nullptr;
+  }
   return result;
 }