Oh dear - that was pretty easy to replicate:

docker run --rm -ti -e PYTHON_VERSION=3.5 -v $PWD:/io matthewbrett/trusty:32 /bin/bash

Then, at that bash prompt:

source /io/test_mpl_py35.sh

Where test_mpl_py35.sh is:

apt-get update
apt-get install -y pkg-config git libpng-dev libz-dev
# Use nipy server for 32-bit wheel
pip install -f https://nipy.bic.berkeley.edu/manylinux numpy
git clone https://github.com/matplotlib/matplotlib.git
export MPLLOCALFREETYPE=1
cd matplotlib
pip install -e .
pip install nose mock sphinx
python tests.py -sv >& test.log

This gives a similar segfault to that above, on the first test run, but on a different test:

matplotlib.tests.test_cycles.test_colorcycle_basic.test ... Fatal Python error: Bus error

Current thread 0xf752c700 (most recent call first):
  File "/venv/lib/python3.5/site-packages/numpy/linalg/linalg.py", line 526 in inv

A second run of the tests gives a similar segfault, but at a yet another test:

matplotlib.tests.test_simplification.test_clipper.test ... Fatal Python error: Bus error

Current thread 0xf74ca700 (most recent call first):
  File "/venv/lib/python3.5/site-packages/numpy/linalg/linalg.py", line 526 in inv

A few tries of nosetests lib/matplotlib/tests/test_cycles.py doesn't generate the segfault, maybe meaning that the process of running the previous tests has made the system prone to crash.

I then tried restoring to a completely vanilla numpy, with system blas and lapack, to see whether it was the OpenBLAS blas / lapack that was causing the segfault:

pip uninstall -y numpy
apt-get install -y libblas-dev liblapack-dev
pip install --no-binary :all: numpy

Rerunning the tests still gives the segfault, but not mentioning linalg this time:

matplotlib.tests.test_mathtext.test_mathtext_cm_53.test ... Fatal Python error: Bus error

Current thread 0xf74a1700 (most recent call first):
  File "/venv/lib/python3.5/site-packages/pyparsing.py", line 170 in __init__

Again, running nosetests lib/matplotlib/tests/test_mathtext.py three times didn't cause the segfault.

The fact that the segfault happened with numpy linked to the system blas / lapack makes me wonder whether this is in fact a matplotlib bug.

does your docker image have enough memory? In the other logs there were a couple of 'out of memory' exceptions, does docker do funny things at the edges?

Is the docker image posted someplace public?

I don't think the image would run out of memory - it's on a beast of a machine in a Berkeley server room somewhere. cat /proc/meminfo gives:

MemTotal:       263851876 kB
MemFree:        14519900 kB

Yes the docker image is public on docker hub - if you run the docker run command above it should pull the docker image down for you - or pull it down beforehand with docker pull matthewbrett/trusty:32.

🐑 Sorry, glossed over the docker details

Tried on a real 32-bit machine, Ubuntu 12.04, with vanilla blas / lapack numpy, got this:

matplotlib.tests.test_axes.test_stackplot.test ... Fatal Python error: Segmentation fault

Current thread 0xb770db00 (most recent call first):
  File "/home/mb312/tmp/mpl-test/matplotlib/lib/matplotlib/backends/backend_agg.py", line 123 in draw_markers
  File "/home/mb312/tmp/mpl-test/matplotlib/lib/matplotlib/collections.py", line 320 in draw

You're welcome to a login to that machine - send me your public ssh key somehow?

coupled to #6604

I think the way we should deal with this is to make the default threshold value configurable. This might also help with getting the tests to pass for the down-stream packagers (as they can turn the knob up for different freetype versions).

The other option is to have pluggable sets of test images for different architectures and freetype versions.

Sets of test images? Please, no!

@tacaswell @efiring Matplotlib wheels being missing on 32-bit architectures is currently blocking scikit-image from releasing. Is any work planned on this issue?

We no longer support Python 3.5.