-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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.
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
Intermittent NRE in SelectExpression.Tags #15710
Comments
just got the same exception on a CI server
re-run with no code changes fixed it. first time i have seen it in months of using EF |
Given the note in preview 6 about the query engine being rewritten (#12795) and that query tags doesn't work right now, it sounds like this specific issue might not exist in the rewritten code. So it can be moved out of the 3.0.0 milestone for now and my team can come back to see if anything like this remains when the new query code stabilises. |
About every 15-20 executions of the unit test suite of our .NET Core 2.2 project we get a NullReferenceException that always end with this stacktrace:
The stack trace leading up to that point comes from various types of EF queries: sync and async, projections, includes, singletons, toarray. There's no pattern that we can see. (A few stack traces are included at the end of the issue). So far we haven't been able to create a small test program that provokes the NRE.
Based on the stack trace we think this is a result of #11575 interacting with #12069, if somehow two threads can end up working with the same
SelectExpression
object inDefaultQuerySqlGenerator
, where one is is accessingSelectExpression.Tags
while the other is callingSelectExpression.DetachContext
. This happens in quick succession here:https://github.com/aspnet/EntityFrameworkCore/blob/2daec6ae17d415af47a606feb0d9f8cfe21296b8/src/EFCore.Relational/Query/Sql/DefaultQuerySqlGenerator.cs#L154
I haven't been able to figure out from the EF Core code if threads can access a single
SelectExpression
, but it is the only explanation I can see so far. If this is the case, a simple workaround that at least would stop the crash might be to changeSelectExpression.Tags
to store away the context locally, like this:But I don't know EF Core enough to be prepared to offer this up as a PR, especially as we can't reliably reproduce it.
Fixing #11601 would probably also fix this issue, and possibly other ones that result from
_queryCompilationContext
no longer beingreadonly
.Steps to reproduce
Unfortunately we have so far only been able to reproduce this sporadically with our full test suite. Some quirks of that suite which may help provoke this behaviour is that a lot of tests are integration tests that all start doing similar queries. When run in parallel two threads might therefore end up running the same query at the same time, which is also the first time in the test run, triggering the bug as described above when both compiles the SQL query.
Further technical details
EF Core version: 2.2.4 and 3.0.0-preview5
Database Provider: Microsoft.EntityFrameworkCore.Sqlite in-memory
Operating system: Windows 10
IDE: Visual Studio Professional 2019 16.0.3 (also seen in VS 2017)
Additional stack traces
The text was updated successfully, but these errors were encountered: