-
Notifications
You must be signed in to change notification settings - Fork 760
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
NullReferenceException in Timer.Dispose() #4985
Comments
@martintmk can you please take a look? |
@klauco This is likely a bug in the FakeTimeProvider implementation, I don't think it's related to resilience logic. |
@martincostello Is it possible your test could possibly be calling Dispose on the timer in two threads and they are racing with one another? Concurrent execution of the Dispose method is the only way I can explain a null reference exception being thrown. |
Also, I think calling Dispose while another thread is currently executing in the ITimer.Change method could also lead to this exception. |
The test is here: MaxDelay_EnsureRespected It doesn't look like it's doing anything on multiple threads, but I did notice that the test is an I don't know why the analysers aren't erroring on that, but I'll open a PR to get rid of them. Given how many dozens/hundreds/more(?) times that test will have run by now since it was added in September, even if that is the cause it's not likely to be immediately provable as the culprit. |
I'm willing to bet the void return was the problem. I'm going to close the issue, please feel free to reopen if you see it happen again. |
Description
In preparing a new release of Polly, our CI failed with the following exception in one of our unit tests. I've never seen this before, so I assume it's a rare race condition:
Looks like the only place in the method that could cause this is this line:
extensions/src/Libraries/Microsoft.Extensions.TimeProvider.Testing/Timer.cs
Line 94 in 52350a9
A trivial fix would be to add a null guard, but the
!
suggests that maybe the proper fix is some other change so that the assertion holds in all cases.Reproduction Steps
Unsure - looks like a rare race condition in the internal state of the
Timer
class.Expected behavior
No exception is thrown.
Actual behavior
NullReferenceException
is thrown.Regression?
I'm guessing it's always been this way.
Known Workarounds
None.
Configuration
8.0.201
8.2.0
Other information
No response
The text was updated successfully, but these errors were encountered: