Closed devbww closed 4 years ago
I recall having a similar issue several months ago (which is what led us to add this test IIRC) but thought we had resolved it... i'll see if I can reconstitute my memory, and I guess this can be my flake for the week.
Are we holding the
grpc::Alarm
incorrectly?
Hard to say, grpc::Alarm
is made out of razor blades and hate... seems like any way you hold it you are lucky to keep all your fingers.
In this case we are simulating the completion of an alarm:
and deleting everything, but that is not guaranteed to work. Alarms must either be canceled or wait until completion, it is not Okay to remove them by yourself.
I will try to fix this.
Oh, I see @mr-salty is already looking. FWIW, I think the right fix is to change that SimulateCompletion()
for nothing and call CancelAll()
to ensure all the timers have actually finished. I think I resisted automatically calling CancelAll()
in the destructor, I think this convinced me I was wrong.
if you'd like to take it, that's fine with me... I do remember us having a longish discussion about this a few months ago but I haven't reviewed that yet to see what thoughts we had (can't recall if the discussion was on a PR/bug, or chat, or email...)
Let me take a look. I need a break from channels/senders/receivers/executors.
This was funny... we have a MockCompletionQueue class that specializes CreateAlarm()
to workaround the crazy timer rules:
But in the tests for CompletionQueue
we used a different mock:
I am running tests again (it used to take 100,000 iterations for this to fail), but I am pretty sure that is the problem...
Are we holding the
grpc::Alarm
incorrectly?cloud-cpp/github/google-cloud-cpp/master/docker/tsan-presubmit failure: