Trying to do something useful on an unhandled exception corrupts all memory. So just abort().

1 files changed, 12 insertions, 5 deletions

diff --git a/src/greenlet/greenlet.cpp b/src/greenlet/greenlet.cpp
index fb81da6..1332d58 100644
--- a/src/greenlet/greenlet.cpp
+++ b/src/greenlet/greenlet.cpp
@@ -1154,11 +1154,18 @@ UserGreenlet::inner_bootstrap(OwnedGreenlet& origin_greenlet, OwnedObject& run)
             result = run.PyCall(args.args(), args.kwargs());
         }
         catch(...) {
-            // Unhandled exception! Try to recover.
-            // If we don't catch this here, most platforms will just
-            // abort() the process. But 64-bit Windows, because of the
-            // way SEH works, can actually corrupt memory.
-            PyErr_SetString(PyExc_RuntimeError, "Unexpected C++ exception caught.");
+            // Unhandled exception! If we don't catch this here, most
+            // platforms will just abort() the process. But on 64-bit
+            // Windows with older versions of the C runtime, this can
+            // actually corrupt memory and just return. We see this
+            // when compiling with the Windows 7.0 SDK targeting
+            // Windows Server 2008, but not when using the Appveyor
+            // Visual Studio 2019 image. So this currently only
+            // affects Python 2.7 on Windows 64. That is, the tests
+            // pass and the runtime aborts. But if we catch it and try
+            // to continue with a Python error, then all Windows 64
+            // bit platforms corrupt memory. So all we can do is abort.
+            abort();
         }
     }
     args.CLEAR();