Skip to content

Conversation

@halter73
Copy link
Member

@halter73 halter73 commented Jan 8, 2020

I saw the following assert failure in System.Memory.Tests

  Starting:    System.Memory.Tests (parallel test collections = off, max threads = 12)
Process terminated. Assertion failed.
   at System.SpanHelpers.LastIndexOf[T](T& searchSpace, T value, Int32 length) in C:\dev\dotnet\runtime\src\libraries\System.Private.CoreLib\src\System\SpanHelpers.T.cs:line 494
   at System.SpanHelpers.LastIndexOf[T](T& searchSpace, Int32 searchSpaceLength, T& value, Int32 valueLength) in C:\dev\dotnet\runtime\src\libraries\System.Private.CoreLib\src\System\SpanHelpers.T.cs:line 478
   at System.SpanTests.SpanTests.LastIndexOfSequenceLengthOneValue_Char() in C:\dev\dotnet\runtime\src\libraries\System.Memory\tests\Span\LastIndexOfSequence.char.cs:line 99
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) in C:\dev\dotnet\runtime\src\coreclr\src\System.Private.CoreLib\src\System\Reflection\RuntimeMethodInfo.cs:line 391
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) in C:\dev\dotnet\runtime\src\libraries\System.Private.CoreLib\src\System\Reflection\MethodBase.cs:line 50
   at Xunit.Sdk.TestInvoker`1.<>c__DisplayClass48_1.<<InvokeTestMethodAsync>b__1>d.MoveNext() in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\Runners\TestInvoker.cs:line 257
   ...

Because of the aggressive inlining, MemoryExtensions.LastIndexOf (a public extension method on Span) doesn't show up in the stack trace, but that's what was calling into the generic SpanHelpers.LastIndexOf method instead of a char-specialized version. I fixed MemoryExtensions.LastIndexOf to call a newly-added char-specialized SpanHelpers.LastIndexOf method.

I also noticed that here are no char-specialized SpanHelpers.LastIndexOfAny methods, so I relaxed the asserts in the generic SpanHelpers.LastIndexOfAny methods.

@jkotas This is a follow up to #1200. Is there an easy way to discover if there are any more assert failures before merging?

@jkotas
Copy link
Member

jkotas commented Jan 9, 2020

I saw the following assert failure in System.Memory.Tests

It makes me worried that you are seeing the asserts, but we are not catching them in the CI.

@dotnet/runtime-infrastructure Are there any tests runs that run debug/checked flavors of everything?

@trylek
Copy link
Member

trylek commented Jan 9, 2020

Both the pre-checkin and the outerloop pipeline only run release bits. AFAIK the only runs that use checked product bits are GC stress and JIT stress runs.

@jkotas
Copy link
Member

jkotas commented Jan 9, 2020

The dotnet/coreclr repo had coverage for running corefx tests on checked coreclr in the CI. This coverage was proven to be important and caught many bugs early. Is there a workitem to add this back? What it would take to add this back?

@trylek
Copy link
Member

trylek commented Jan 9, 2020

I know we discussed that with @BruceForstall when I was working on the PR

#520

but looking now I cannot find an explicit item - Bruce, do you know whether there is one or whether I should create a new one?

@safern
Copy link
Member

safern commented Jan 9, 2020

What it would take to add this back?

With the single pipeline effort that I'm doing this will be simplified. I might just include running corefx tests on checked coreclr (regular runs, not stress) when coreclr is touched.

#1473

@BruceForstall
Copy link
Contributor

I have a work item to add back libraries testing on checked coreclr for coreclr checkins, but I've been waiting for the merged repo and live/live CI changes to stabilize before doing that... and maybe @safern's work will make it easy or do it for me.

@safern
Copy link
Member

safern commented Jan 9, 2020

@safern's work will make it easy or do it for me.

Yeah, let's sync up after I'm done, I have some ideas.

@jkotas
Copy link
Member

jkotas commented Jan 10, 2020

@dotnet/runtime-infrastructure A lot of legs are failing with "RestApiException: The response contained an invalid status code 500 Internal Server Error". I am not able to figure out what the problem is - can't find any logs with details. Could you please take a look?

@dagood
Copy link
Member

dagood commented Jan 10, 2020

500 Internal Server Error

That's happening across a bunch of PRs, including one I'm working on. Filed https://github.com/dotnet/core-eng/issues/8591 to track.

@safern
Copy link
Member

safern commented Jan 10, 2020

So in my PR I'm adding some corefx test runs with a checked runtime and it did hit this issue:

#1473

https://helix.dot.net/api/2019-06-17/jobs/f278b756-269f-4001-a23d-2a50fd10ef56/workitems/System.Memory.Tests/console

I will pull up this change and see if it fixes it.

@safern
Copy link
Member

safern commented Jan 11, 2020

@jkotas
Copy link
Member

jkotas commented Jan 11, 2020

Let's revert the change that added the asserts for now, so that you can get the changes that are fixing the CI coverage in: #1628

@stephentoub
Copy link
Member

Should this be closed now?

@jkotas
Copy link
Member

jkotas commented Jan 15, 2020

Opened #1767 to track the follow up.

@jkotas jkotas closed this Jan 15, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants