runtime: tracing\eventpipe\providervalidation\providervalidation\providervalidation.cmd fails in gcstress3, Windows x86
This test fails in the CI in the last 3 runs of Windows x86 GCStress=0x3:
\r\nAssert failure(PID 4216 [0x00001078], Thread: 7224 [0x1c38]): Consistency check failed: Invalid transition into managed code!\r\n\r\nWe're walking this thread's stack and we've reached a managed frame at Esp=0x00F7D758. (The method is Advapi32::EventWriteTransfer_PInvoke) The very next FS:0 record (0x00F7D760) up from this point on the stack should be one of our 'unmanaged to managed SEH handlers', but its not... its something else, and that's very bad. It indicates that someone managed to call into managed code without setting up the proper exception handling.\r\n\r\nGet a good unmanaged stack trace for this thread. All FS:0 records are on the stack, so you can see who installed the last handler. Somewhere between that function and where the thread is now is where the bad transition occurred.\r\n\r\nA little extra info: FS:0 = 0x00F7D370, pEHR->Handler = 0x72E381BD\r\nFAILED: IsUnmanagedToManagedSEHHandler(pEHR)\r\n\r\nCORECLR! CHECK::Trigger + 0x2FB (0x727675be)\r\nCORECLR! VerifyValidTransitionFromManagedCode + 0x165 (0x7283af20)\r\nCORECLR! StackFrameIterator::NextRaw + 0x887 (0x72806395)\r\nCORECLR! StackFrameIterator::Next + 0x46 (0x72805aca)\r\nCORECLR! Thread::StackWalkFramesEx + 0x180 (0x7280705c)\r\nCORECLR! Thread::StackWalkFrames + 0x159 (0x72806e5c)\r\nCORECLR! ScanStackRoots + 0x198 (0x72cbc639)\r\nCORECLR! GCToEEInterface::GcScanRoots + 0x104 (0x72cbb9b6)\r\nCORECLR! WKS::gc_heap::mark_phase + 0x1AD (0x72c71931)\r\nCORECLR! WKS::gc_heap::gc1 + 0x167 (0x72c6bb08)\r\n File: F:\workspace\_work\1\s\src\coreclr\src\vm\i386\excepx86.cpp Line: 329\r\n Image: C:\h\w\A86D08D2\p\CoreRun.exe\r\n\r\n\r\nReturn code: 1\r\nRaw output file: C:\h\w\A86D08D2\w\9D9C0906\e\tracing\eventpipe\Reports\tracing.eventpipe\providervalidation\providervalidation\providervalidation.output.txt\r\nRaw output:\r\nBEGIN EXECUTION\r\n "C:\h\w\A86D08D2\p\corerun.exe" providervalidation.dll \r\n 0.0s: ==TEST STARTING==\r\n 5.6s: Started sending sentinel events...\r\n 6.0s: Connecting to EventPipe...\r\n 10.5s: Connected to EventPipe with sessionID '0x7633a78'\r\n 10.5s: Creating EventPipeEventSource...\r\n 22.7s: EventPipeEventSource created\r\n 26.4s: Dynamic.All callback registered\r\n 26.4s: Starting stream processing...\r\n 33.4s: Saw new provider 'Microsoft-DotNETCore-SampleProfiler'\r\n 50.9s: Saw sentinel event\r\n 51.0s: Stopped sending sentinel events\r\n 51.3s: Starting event generating action...\r\n 66.5s: Fired MyEvent 0/100,000 times...\r\n 70.3s: Saw new provider 'MyEventSource'\r\n 74.1s: Fired MyEvent 10,000/100,000 times...\r\n 75.0s: Fired MyEvent 20,000/100,000 times...\r\nExpected: 100\r\nActual: -1073740286\r\nEND EXECUTION - FAILED\r\nFAILED\r\nTest Harness Exitcode is : 1\r\nTo run the test:\r\n> set CORE_ROOT=C:\h\w\A86D08D2\p\r\n> C:\h\w\A86D08D2\w\9D9C0906\e\tracing\eventpipe\providervalidation\providervalidation\providervalidation.cmd\r\nExpected: True\r\nActual: False
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 21 (20 by maintainers)
Yes, that may be one option. Another option is to make the JIT to pass the size of the stack-arguments to
JIT_PInvokeBeginhelper, on x86 only.