From a02057292b306e4d697f9767b9176c4a8a2b7e93 Mon Sep 17 00:00:00 2001 From: "Jake.Stine" Date: Wed, 29 Sep 2010 11:29:21 +0000 Subject: [PATCH] w32pthreads: remove some unnecessary cleanup code being run on critical errors, which was only causing confusion when debugging thread crashes. git-svn-id: http://pcsx2.googlecode.com/svn/trunk@3856 96395faa-99c1-11dd-bbfe-3dabce05a288 --- 3rdparty/w32pthreads/ptw32_threadStart.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/3rdparty/w32pthreads/ptw32_threadStart.c b/3rdparty/w32pthreads/ptw32_threadStart.c index f4893ce1d7..eff4f49457 100644 --- a/3rdparty/w32pthreads/ptw32_threadStart.c +++ b/3rdparty/w32pthreads/ptw32_threadStart.c @@ -102,10 +102,18 @@ ExceptionFilter (EXCEPTION_POINTERS * ep, DWORD * ei) * routine. We need to cleanup before letting the exception * out of thread scope. */ - pthread_t self = pthread_self (); - (void) pthread_mutex_destroy (&((ptw32_thread_t *)self.p)->cancelLock); - ptw32_callUserDestroyRoutines (self); + // Air Says: No we don't. If a structured exception makes it this far, the program is + // screwed anyway (will cause a GPF / close program dialog to the user) and so a little lost + // cleanup isn't going to matter anyway. Furthermore, no other stack objects are + // getting unwound, so if anything in the User destroy routines are dependent on other + // stack objects being unwound, it'll cause a secondary premature crash which can confuse + // debugging efforts. There is a reason microsoft recommends *not* doing much of anything + // from the context of an exception filter... --air + + //pthread_t self = pthread_self (); + //(void) pthread_mutex_destroy (&((ptw32_thread_t *)self.p)->cancelLock); + //ptw32_callUserDestroyRoutines (self); return EXCEPTION_CONTINUE_SEARCH; break;