pytest node crashes on windows in cirq_google serialization tests

[maffoo]

Description of the issue

I've seen a few pytest failures on windows in cirq-google serialization tests:

[gw1] win32 -- Python 3.7.9 c:\hostedtoolcache\windows\python\3.7.9\x64\python.exe
worker 'gw1' crashed while running 'cirq-google/cirq_google/serialization/serializable_gate_set_test.py::test_deserialize_infinite_recursion_fails'

I've seen this happen both in 3.7 tests and in 3.9 tests. Seems to be intermittent.

[95-martin-orion]

I've also seen this error, but at the time chalked it up to Github Actions runner instability. Seeing that it's still coming up - and that it's in the infinite recursion test - suggests I should revisit my code here.

[maffoo]

It does say right in the test it's doing something sketchy :-)

# Maliciously modify the CircuitOperation to be self-referencing.

[95-martin-orion]

#4315 for context on what this test is about. The deserialization half of this test is fine - it will try to locate the recursively-defined operation in the constants map, fail, and error out.

The serialization half intentionally forces a RecursionError, but it's the safer variety: Python notices that the a method was called with the exact same arguments and system state and it fails after a single recursive call. It doesn't seem like this could cause a crash unless the Windows runners (a) disabled this recursion safeguard in their Python config, and (b) encountered a hardware issue (OOM, maybe worse?) before the "too many recursive calls" error triggered.

Given all of that, I feel pretty safe labeling this particular bit of malicious code as de-fanged 😝 Good to keep an eye on this, but at the moment it seems like only a minor nuisance.

[mhucka]

Closing because this crash does not seem to occur anymore, and I can't find the "Maliciously modify …" comment in the code. (Which is too bad, because that's a hilarious comment.) (If someone thinks that's the wrong call, please add a comment here and reopen it.)