I'm not sure I follow this 100%, but just a thought looking at the caching in text.py and mathtext.py:

    def get_prop_tup(self, renderer=None):
        """
        Return a hashable tuple of properties. ...
        """
        x, y = self.get_unitless_position()
        return (x, y, self.get_text(), self._color,
                self._verticalalignment, self._horizontalalignment,
                hash(self._fontproperties),
                self._rotation, self._rotation_mode,
                self.figure.dpi, id(renderer or self._renderer),
                )

    def parse(self, s, dpi = 72, prop = None):
        ...
        cacheKey = (s, dpi, hash(prop))
        result = self._cache.get(cacheKey)
        if result is not None:
            return result

Both use hash(prop) as part of the cache key. What the hash function guarantees is that if two objects are equal they have the same hash value, not the other way around. Could we be getting an occasional hash collision?

In these tests, the FontProperties are exactly the same across the 5 fontsets. It's only the mathtext.fontset rcParam that changes, but it's only checked in mathtext.py while the cached layout is found in text.py.

Suspect it as a new render which has the same id ( https://stackoverflow.com/questions/20753364/why-is-the-id-of-a-python-class-not-unique-when-called-quickly and I have hit this at my day-job).

The fix looks like it is give renderers some sort of unique id (uuid4 or just a random number) and use that instead of using id. Maybe also put it first so that it fails-fast if on a different renderer.

Exact work:

• add _uid attribute to backend_bases.py:RendererBase
• change Text.get_prop_tuple to use that _uid instead of id() to identify the renderer. This needs to account for the renderers being None and be back compatible with non-derived-from-us renderers, something like getatter(renderer, '_id', None) or getattr(self._renderer, '_id) or id(renderer or self._renderer)
• document the (private) API change

Testing this is hard given that it relies on triggering a race condition inside of cpython.

Any progress here? It seems to me that around half of the daily wheel build / test runs fail with one of these errors - I mean, there's one run in the build matrix that fails, meaning I have to go and restart that build manually.

On master? They should be marked to re-run on failure.

Yes, on master. This is using pytest.

Errors continue, at or around 50% of build runs. Here's the latest build matrix:

https://travis-ci.org/MacPython/matplotlib-wheels/builds/234736344

Failure build log:

https://travis-ci.org/MacPython/matplotlib-wheels/jobs/234736346

This is another plea for a progress update, it's tiring to restart builds by hand every other day.

I've added pytest-rerunfailures to the wheel building repo, as workaround. But, I guess this issue is also going to come up for people running tests on their own machine.

I suspect that this failure is rare in real life as it is a consequence of running a somewhat pathological test where all of these values are the same:

        return (x, y, self.get_text(), self._color,
                self._verticalalignment, self._horizontalalignment,
                hash(self._fontproperties),
                self._rotation, self._rotation_mode,
                self.figure.dpi, id(renderer or self._renderer),
                self._linespacing
                )

but with different renderers and rapidly changing rcParams.

For what ever reason, these collisions seem to happen far more often on travis than on my machines. I assume this has something to do with travis being all VMs and / or low memory?

Ah, I thought you were already using the rerunfailures plugin; that's what cut down on the failures on master. #7107 is marked as hard, so I'm not sure why this issue is new-contributor-friendly, but perhaps there's some way to modify only the tests to work nicely.

It's a bit of a hack, but what if we empty Text._cached at the end of each of these tests? The shear number of these tests is already a bit of a time sink, so this may or may not be a good idea.