Fix an assert failure in GCStress testing

When GCStress uses redirection, it pushes a
RedirectedThreadFrame (Windows) or
ResumableFrame(Unix) on the stack.

The stack walker, when checking for consistency of frame chain
makes a special case for this redirection when running under
GCStress -- but compares only against `RedirectedThreadFrame'.
This caused the StackWalker to think that certain invoke-s were
not redirected, resulting in the failures in some GCStress tests
on Linux.

This change fixes the problem.
Fixes #2848

src/vm/stackwalk.cpp

@@ -1564,8 +1564,8 @@ BOOL StackFrameIterator::IsValid(void)
         // we started?
         //DevDiv 168789: In GCStress >= 4 two threads could race on triggering GC;
         //  if the one that just made p/invoke call is second and hits the trap instruction
-        //  before call to syncronize with GC, it will push RedirectedThreadFrame concurrently 
-        //  with GC stackwalking.
+        //  before call to syncronize with GC, it will push a frame [ResumableFrame on Unix 
+        //  and RedirectedThreadFrame on Windows] concurrently with GC stackwalking.
         //  In normal case (no GCStress), after p/invoke, IL_STUB will check if GC is in progress and syncronize.
         BOOL bRedirectedPinvoke = FALSE;
 
@@ -1576,7 +1576,8 @@ BOOL StackFrameIterator::IsValid(void)
                               (m_pRealStartFrame->GetVTablePtr() == InlinedCallFrame::GetMethodFrameVPtr()) && 
                               (m_pThread->GetFrame() != NULL) &&
                               (m_pThread->GetFrame() != FRAME_TOP) &&
-                              (m_pThread->GetFrame()->GetVTablePtr() == RedirectedThreadFrame::GetMethodFrameVPtr()));
+                              ((m_pThread->GetFrame()->GetVTablePtr() == ResumableFrame::GetMethodFrameVPtr()) ||
+                               (m_pThread->GetFrame()->GetVTablePtr() == RedirectedThreadFrame::GetMethodFrameVPtr())));
 #endif // FEATURE_HIJACK
 
         _ASSERTE( (m_pStartFrame != NULL) ||