Source generator tests failing with AV in Roslyn #102919
Assignees
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
blocking-clean-ci
Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'
Known Build Error
Use this to report build issues in the .NET Helix tab
Priority:1
Work that is critical for the release, but we could probably ship without
Milestone
Comments
kunalspathak
added
blocking-clean-ci
dotnet-policy-service
bot
added
the
untriaged
|
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions |
stephentoub
added
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
jkotas
changed the title
|
Stacktrace of the failure: |
|
The CI failure is missing crash dump. It is not actionable. cc @JulieLeeMSFT |
|
@jkotas, Juan looked into it. AccessViolationException shows that xunit is suppressing the exception making the process not crash. So, we won't get a crash dump in this case.
|
JulieLeeMSFT
added
Priority:1
|
|
|
Ok, there is a regression in EH that makes us to not produce crash dumps on access violations. Opened: #103018 |
|
Trying to get a local repro, no luck so far. Suspect it will require another hit in CI. |
|
There is a failure from a couple of days ago now that has a crash dump it looks like. |
|
Analysis for build 709265:
Actual AnalyzedArguments value: Expected AnalyzedArguments value from |
|
Analysis for build 705911:
Actual AnalyzedArguments value: Expected AnalyzedArguments value from |
|
@VSadov Could you please take a look? The symptoms suggest that we are missing GC reporting for |
|
I will take a look. |
|
This particular crash signature is that rare. It is likely that there are other failures caused by the same underlying bug. |
|
Also - from stacks it looks like it is the compiler crashing (so bug would be in the toolset runtime), or is it in the actual tests? |
|
The crash is in source generator tests. It is running on live built runtime. |
|
I am able to repro (to get a GC stress failure) on these tests. Not sure what the reasons for it yet. |
|
It looks like something is happening when The failure happens when we call Relocate and the argument Right now it does not look like a problem with root reporting. We seem to report roots correctly and arg |
|
Suppressing |
|
The suspicious part is that we can have Perhaps this is another variant of #102577 - we have replaced uninterrupted sequence with one that has a call in it and something is not ready for that. bool found = TryPerformConstructorOverloadResolution(namedTypeSymbol, instance, ".ctor", location, suppressResultDiagnostics: false, diagnostics, out memberResolutionResult, out candidateConstructors, allowProtectedConstructorsOfBaseType: true, out useSiteInfo2);
return BindConstructorInitializerCoreContinued(found, initializerArgumentListOpt, constructor, instance, returnType, namedTypeSymbol, flag, cSharpSyntaxNode2, location, enableCallerInfo, memberResolutionResult, candidateConstructors, in useSiteInfo2, diagnostics); call [Microsoft.CodeAnalysis.CSharp.Binder:TryPerformConstructorOverloadResolution(Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,System.String,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag,byref,byref,ubyte,byref,ubyte):ubyte:this]
; gcrRegs -[rcx rdx r8-r9]
; gcr arg pop 0
mov dword ptr [rbp-0x30C], eax
mov r9, gword ptr [rbp-0x318]
; gcrRegs +[r9]
mov gword ptr [rsp+0x20], r9
; gcr arg write
mov r10, gword ptr [rbp-0x320]
; gcrRegs +[r10]
mov gword ptr [rsp+0x28], r10
; gcr arg write
mov r11, gword ptr [rbp-0x328]
; gcrRegs +[r11]
mov gword ptr [rsp+0x30], r11
; gcr arg write
mov r8d, dword ptr [rbp-0x3C]
mov dword ptr [rsp+0x38], r8d
mov gword ptr [rsp+0x40], r15
; gcr arg write
mov gword ptr [rsp+0x48], r13
; gcr arg write
mov r15d, dword ptr [rbp-0x40]
; gcrRegs -[r15]
mov dword ptr [rsp+0x50], r15d
lea rcx, bword ptr [rbp-0x2E8]
; byrRegs +[rcx]
lea rdx, [rbp-0xC0]
mov r8d, 128
; GC ptr vars -{V06 V07}
call CORINFO_HELP_BULK_WRITEBARRIER <============
; gcrRegs -[r9-r11 r13]
; byrRegs -[rcx]
; gcr arg pop 0
mov rdx, gword ptr [rbp-0xC8]
; gcrRegs +[rdx]
mov gword ptr [rsp+0x60], rdx
; gcr arg write
lea rdx, [rbp-0xE8]
; gcrRegs -[rdx]
mov qword ptr [rsp+0x68], rdx
mov gword ptr [rsp+0x70], rsi
; gcr arg write
mov edx, dword ptr [rbp-0x30C]
lea r8, [rbp-0x2E8]
mov qword ptr [rsp+0x58], r8
mov r8, rbx
; gcrRegs +[r8]
mov r9, r14
; gcrRegs +[r9]
mov rcx, rdi
; gcrRegs +[rcx]
call [Microsoft.CodeAnalysis.CSharp.Binder:BindConstructorInitializerCoreContinued(ubyte,Microsoft.CodeAnalysis.CSharp.Syntax.ArgumentListSyntax,Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol,Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,ubyte,Microsoft.CodeAnalysis.CSharp.CSharpSyntaxNode,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.MemberResolutionResult`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],System.Collections.Immutable.ImmutableArray`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],byref,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag):Microsoft.CodeAnalysis.CSharp.BoundExpression:this]
; gcrRegs -[rcx rbx rsi rdi r8-r9 r14] +[rax]
; gcr arg pop 0Two questions:
|
|
cc @EgorBo |
|
Without call [Microsoft.CodeAnalysis.CSharp.Binder:TryPerformConstructorOverloadResolution(Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,System.String,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag,byref,byref,ubyte,byref,ubyte):ubyte:this]
; gcrRegs -[rcx rdx r8-r9]
; gcr arg pop 0
mov edx, eax
mov r9, gword ptr [rbp-0x318]
; gcrRegs +[r9]
mov gword ptr [rsp+0x20], r9
; gcr arg write
mov r10, gword ptr [rbp-0x320]
; gcrRegs +[r10]
mov gword ptr [rsp+0x28], r10
; gcr arg write
mov r11, gword ptr [rbp-0x328]
; gcrRegs +[r11]
mov gword ptr [rsp+0x30], r11
; gcr arg write
mov r8d, dword ptr [rbp-0x3C]
mov dword ptr [rsp+0x38], r8d
mov gword ptr [rsp+0x40], rsi
; gcr arg write
mov gword ptr [rsp+0x48], rdi
; gcr arg write
mov esi, dword ptr [rbp-0x40]
; gcrRegs -[rsi]
mov dword ptr [rsp+0x50], esi
lea rdi, bword ptr [rbp-0x2E8]
; gcrRegs -[rdi]
; byrRegs +[rdi]
lea rsi, bword ptr [rbp-0xC0]
; byrRegs +[rsi]
mov ecx, 16
rep movsq
mov r8, gword ptr [rbp-0xC8]
; gcrRegs +[r8]
mov gword ptr [rsp+0x60], r8
; gcr arg write
lea r8, [rbp-0xE8]
; gcrRegs -[r8]
mov qword ptr [rsp+0x68], r8
mov gword ptr [rsp+0x70], r14
; gcr arg write
lea r8, [rbp-0x2E8]
mov qword ptr [rsp+0x58], r8
mov r8, rbx
; gcrRegs +[r8]
mov r9, r13
mov rcx, r15
; gcrRegs +[rcx]
; GC ptr vars -{V06 V07}
call [Microsoft.CodeAnalysis.CSharp.Binder:BindConstructorInitializerCoreContinued(ubyte,Microsoft.CodeAnalysis.CSharp.Syntax.ArgumentListSyntax,Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol,Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,ubyte,Microsoft.CodeAnalysis.CSharp.CSharpSyntaxNode,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.MemberResolutionResult`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],System.Collections.Immutable.ImmutableArray`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],byref,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag):Microsoft.CodeAnalysis.CSharp.BoundExpression:this]
; gcrRegs -[rcx rbx r8-r11 r13-r15] +[rax]
; byrRegs -[rsi rdi]
; gcr arg pop 0The issue of suspension starvation is mitigated for stack pushes by the fact that stacks sizes are in order of megabytes and that is very limiting to how long it could take to make these copies. If we ever want to support much larger stacks, methods that push a lot could be made fully interruptible and use the helper. I think that would work, since fully interruptible code tracks argument pushes. |
Thanks! I'll take a look, presumably it's not this helper specific as there are other managed helpers |
|
The fundamental problem here is most likely #103300 (#103300 (comment) is basically this issue I'd expect). Can you check if #103301 fixes the issue? |
|
@jakobbotsch I think #103301 should help. I will check. |
|
#103301 puts I have run the repro in a loop, to be sure. It has run through more than enough iterations to typically see failures, but so far it keeps running. call [Microsoft.CodeAnalysis.CSharp.Binder:TryPerformConstructorOverloadResolution(Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,System.String,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag,byref,byref,ubyte,byref,ubyte):ubyte:this]
; gcrRegs -[rcx rdx r8-r9]
; gcr arg pop 0
mov dword ptr [rbp-0x30C], eax
lea rcx, bword ptr [rbp-0x2E8]
; byrRegs +[rcx]
lea rdx, [rbp-0xC0]
mov r8d, 128
call CORINFO_HELP_BULK_WRITEBARRIER <-- now before all putargs
; byrRegs -[rcx]
; gcr arg pop 0
mov rdx, gword ptr [rbp-0xC8]
; gcrRegs +[rdx]
mov gword ptr [rsp+0x60], rdx
; gcr arg write
lea rdx, [rbp-0xE8]
; gcrRegs -[rdx]
mov qword ptr [rsp+0x68], rdx
mov gword ptr [rsp+0x70], rsi
; gcr arg write
mov edx, dword ptr [rbp-0x30C]
lea r8, [rbp-0x2E8]
mov qword ptr [rsp+0x58], r8
mov r8, rbx
; gcrRegs +[r8]
mov r9, r14
; gcrRegs +[r9]
mov rcx, rdi
; gcrRegs +[rcx]
mov r10, gword ptr [rbp-0x318]
; gcrRegs +[r10]
mov gword ptr [rsp+0x20], r10
; gcr arg write
mov rbx, gword ptr [rbp-0x320]
mov gword ptr [rsp+0x28], rbx
; gcr arg write
mov rbx, gword ptr [rbp-0x328]
mov gword ptr [rsp+0x30], rbx
; gcr arg write
mov edi, dword ptr [rbp-0x3C]
; gcrRegs -[rdi]
mov dword ptr [rsp+0x38], edi
mov gword ptr [rsp+0x40], r15
; gcr arg write
mov gword ptr [rsp+0x48], r13
; gcr arg write
mov ebx, dword ptr [rbp-0x40]
; gcrRegs -[rbx]
mov dword ptr [rsp+0x50], ebx
; GC ptr vars -{V06 V07}
call [Microsoft.CodeAnalysis.CSharp.Binder:BindConstructorInitializerCoreContinued(ubyte,Microsoft.CodeAnalysis.CSharp.Syntax.ArgumentListSyntax,Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol,Microsoft.CodeAnalysis.CSharp.AnalyzedArguments,Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol,Microsoft.CodeAnalysis.CSharp.Symbols.NamedTypeSymbol,ubyte,Microsoft.CodeAnalysis.CSharp.CSharpSyntaxNode,Microsoft.CodeAnalysis.Location,ubyte,Microsoft.CodeAnalysis.CSharp.MemberResolutionResult`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],System.Collections.Immutable.ImmutableArray`1[Microsoft.CodeAnalysis.CSharp.Symbols.MethodSymbol],byref,Microsoft.CodeAnalysis.CSharp.BindingDiagnosticBag):Microsoft.CodeAnalysis.CSharp.BoundExpression:this]
; gcrRegs -[rcx rsi r8-r10 r13-r15] +[rax]
; gcr arg pop 0 |
|
Thanks for confirming. I can grab this one. |
|
@EgorBo I still think that if we can know statically that the dest is on stack, we might not want to involve We use the |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=693513
Build error leg or test failing: System.Text.RegularExpressions.Tests.RegexPcre2Tests.IsMatchTests
Pull request: #102903
Error Message
Fill the error message using step by step known issues guidance.
{ "ErrorMessage": [ "System.AccessViolationException", "Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CompileMethods" ], "BuildRetry": false, "ExcludeConsoleLog": false }Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=693513
Error message validated:
[System.AccessViolationException Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CompileMethods]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 5/31/2024 5:13:05 PM UTC
Report
Summary
The text was updated successfully, but these errors were encountered: