Skip to content

Conversation

akarnokd
Copy link
Collaborator

@akarnokd akarnokd commented Jun 8, 2018

For some reason, dotCover would hang in various timed test which use the DefaultScheduler. I don't know why, but removing that empty try-catch along with the atomic dispose management solves the issue.

In addition, the Virtual_ThreadSafety() was running extremely slow in its original form (more than 5 minutes). The reduced time amount and a more close thread-synchronization should be faster now while preserving the behavior under test.

{
_action = Stubs<object>.Ignore;
_timer = TimerStubs.Never;
_state = null;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a race here where _state could be set null but the timer will execute, passing the wrong state (it doesn't help that _action is set to Stubs.Ignore before, that might be rearranged). Maybe timer._action should only be called when TryDispose was true, setting _action and _state by itself (or by some DisposeCore method)?

@danielcweber
Copy link
Collaborator

Do you know anything about the issue or bug here? Seems that the SpinWait would loop forever?

@akarnokd
Copy link
Collaborator Author

I don't know, I can't switch to debug while running with coverage enabled. Maybe there is a way to trigger a thread dump externally?

@danielcweber
Copy link
Collaborator

I could give it a try.

@danielcweber
Copy link
Collaborator

Do you know what process will eventually host our code? Everything I debug doesn't run anything form System.Reactive.

@akarnokd
Copy link
Collaborator Author

Either a dotnet.exe or dottest.exe. Usually the one with high CPU usage but here, it probably hangs thus there is no CPU usage.

@danielcweber
Copy link
Collaborator

I can't reproduce the hanging tests under coverage. Virtual_ThreadSafety() running slow is understandable, it takes a lot of loops and AdvanceBy to actually trigger the virtual scheduler.

@akarnokd
Copy link
Collaborator Author

Were you running dotCover or microsoft's own coverage tool of VS Enterprise?

@danielcweber
Copy link
Collaborator

DotCover within VS

@akarnokd
Copy link
Collaborator Author

There could be a probabilistic signal loss from the timer.

You could try and add a loop around the body of Delay_TimeSpan_DefaultScheduler for example, usually 1.000 - 10.000 iterations.

        [Fact]
        public void Delay_TimeSpan_DefaultScheduler()
        {
            for (int i = 0;  i < 10000; i++)    
                Assert.True(Observable.Return(1).Delay(TimeSpan.FromMilliseconds(1))
                   .ToEnumerable().SequenceEqual(new[] { 1 }));
        }

@danielcweber
Copy link
Collaborator

Can't really reproduce it but the fix is straightforward and the SpinWait-solution is wacky enough that this should be merged.

@danielcweber danielcweber merged commit 11506de into dotnet:master Jun 11, 2018
@akarnokd akarnokd deleted the DotCoverTestFixes branch June 26, 2018 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants