Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Test failure Interop\\ICustomMarshaler\\Primitives\\ICustomMarshaler_TargetWindows\\ICustomMarshaler_TargetWindows.cmd #50404

Closed
VincentBu opened this issue Mar 30, 2021 · 0 comments · Fixed by #50544
Closed

Test failure Interop\\ICustomMarshaler\\Primitives\\ICustomMarshaler_TargetWindows\\ICustomMarshaler_TargetWindows.cmd #50404

VincentBu opened this issue Mar 30, 2021 · 0 comments · Fixed by #50544
Assignees
@BruceForstall
Labels
arch-x64 area-Interop-coreclr GCStress os-windows
Milestone
6.0.0

Comments

@VincentBu
Copy link
Contributor

Run: runtime-coreclr gcstress-extra 20210328.1

Failed test:

CoreCLR windows x64 Checked gcstress0xc_zapdisable_jitstress2 @ Windows.10.Amd64.Open
 -Interop\\ICustomMarshaler\\Primitives\\ICustomMarshaler_TargetWindows\\ICustomMarshaler_TargetWindows.cmd

Error message:

Assert failure(PID 6160 [0x00001810], Thread: 6688 [0x1a20]): !CREATE_CHECK_STRING(!"Detected use of a corrupted OBJECTREF. Possible GC hole.")

CORECLR! Object::ValidateInner'::1'::catch$12 + 0x137 (0x00007ffe5c97b407)
CORECLR! CallSettingFrame_LookupContinuationIndex + 0x20 (0x00007ffe5c8e0650)
CORECLR! _FrameHandler4::CxxCallCatchBlock + 0x1DE (0x00007ffe5c8de5ce)
NTDLL! RtlCaptureContext + 0x3C3 (0x00007ffe8afe9b23)
CORECLR! Object::ValidateInner + 0xEE (0x00007ffe5c26926e)
CORECLR! Object::Validate + 0xB9 (0x00007ffe5c269149)
CORECLR! GcInfoDecoder::ReportRegisterToGC + 0x127 (0x00007ffe5c68007f)
CORECLR! GcInfoDecoder::ReportSlotToGC + 0xCD (0x00007ffe5c6802ad)
CORECLR! GcInfoDecoder::EnumerateLiveSlots + 0xCE5 (0x00007ffe5c67f4b1)
CORECLR! EECodeManager::EnumGcRefs + 0x389 (0x00007ffe5c176459)
 File: D:\workspace\_work\1\s\src\coreclr\vm\object.cpp Line: 591
 Image: C:\h\w\B97A09A8\p\corerun.exe


Return code: 1
Raw output file: C:\h\w\B97A09A8\w\ABE408F0\e\Interop\ICustomMarshaler\Reports\Interop.ICustomMarshaler\Primitives\ICustomMarshaler_TargetWindows\ICustomMarshaler_TargetWindows.output.txt
Raw output:
BEGIN EXECUTION
 "C:\h\w\B97A09A8\p\corerun.exe" ICustomMarshaler_TargetWindows.dll 
Discovering...
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
FAILED
Test Harness Exitcode is : 1
To run the test:
> set CORE_ROOT=C:\h\w\B97A09A8\p
> C:\h\w\B97A09A8\w\ABE408F0\e\Interop\ICustomMarshaler\Primitives\ICustomMarshaler_TargetWindows\ICustomMarshaler_TargetWindows.cmd
Expected: True
Actual: False

Stack trace
   at Interop_ICustomMarshaler._Primitives_ICustomMarshaler_TargetWindows_ICustomMarshaler_TargetWindows_._Primitives_ICustomMarshaler_TargetWindows_ICustomMarshaler_TargetWindows_cmd()
@dotnet-issue-labeler dotnet-issue-labeler bot added area-Interop-coreclr untriaged New issue has not been triaged by the area owner labels Mar 30, 2021
BruceForstall added a commit to BruceForstall/runtime that referenced this issue Apr 1, 2021
@BruceForstall
Fix GC overreporting with generics context + GS cookie
590cd5c 
This is a case of a generics context in `this` where we need to keep
`this` alive (but aren't required to by the VM) with a GS cookie check
(due to "JitStress: STRESS_UNSAFE_BUFFER_CHECKS"), and maybe other
JitStress modes, where `genEmitGSCookieCheck` decides to use `rcx`
to load the cookie, even though it is alive. `this` is also mostly
in a register, but it reported live as a stack slot. When the GS
cookie label gets created, the "codegen" gc info hasn�t been updated
with the killed register, so the emitter label gets the wrong GC info
and brings rcx back alive just for the `nop`. GC cookie checks kind
of do their own register allocation since they�re part of the epilogs.

The GS cookie code checks for keep alive using "lvRegister", but that
isn't set, since the cookie is mostly alive in a stack slock, not
always in a register. Use `lvIsInReg()` instead, so GS cookie check
will use RDX to load the cookie instead.

Fixes dotnet#50404
@BruceForstall BruceForstall mentioned this issue Apr 1, 2021
Merged
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Apr 1, 2021
@AaronRobinsonMSFT AaronRobinsonMSFT removed the untriaged New issue has not been triaged by the area owner label Apr 1, 2021
@AaronRobinsonMSFT AaronRobinsonMSFT added this to the 6.0.0 milestone Apr 1, 2021
BruceForstall added a commit that referenced this issue Apr 1, 2021
@BruceForstall
Fix GC overreporting with generics context + GS cookie (#50544)
60d169b 
This is a case of a generics context in `this` where we need to keep
`this` alive (but aren't required to by the VM) with a GS cookie check
(due to "JitStress: STRESS_UNSAFE_BUFFER_CHECKS"), and maybe other
JitStress modes, where `genEmitGSCookieCheck` decides to use `rcx`
to load the cookie, even though it is alive. `this` is also mostly
in a register, but it reported live as a stack slot. When the GS
cookie label gets created, the "codegen" gc info hasn�t been updated
with the killed register, so the emitter label gets the wrong GC info
and brings rcx back alive just for the `nop`. GC cookie checks kind
of do their own register allocation since they�re part of the epilogs.

The GS cookie code checks for keep alive using "lvRegister", but that
isn't set, since the cookie is mostly alive in a stack slock, not
always in a register. Use `lvIsInReg()` instead, so GS cookie check
will use RDX to load the cookie instead.

Fixes #50404
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Apr 1, 2021
@AaronRobinsonMSFT AaronRobinsonMSFT mentioned this issue Apr 3, 2021
Closed
@ghost ghost locked as resolved and limited conversation to collaborators May 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@BruceForstall BruceForstall

Labels
arch-x64 area-Interop-coreclr GCStress os-windows
Projects
None yet
Milestone
6.0.0
Development

Successfully merging a pull request may close this issue.

Fix GC overreporting with generics context + GS cookie BruceForstall/runtime
3 participants
@BruceForstall @AaronRobinsonMSFT @VincentBu