That is a fun bug and can confirm it on master.

This so probably something subtle deep in the callback code so I am tagging this as 1.4.x (instead of 1.4.0).

Perhaps there is a subtle assumption that shared axes must be on the same
figure. Aren't callbacks tied to the figure object? With the weakrefs in
the callback architecture, I would wonder if closing out figures that have
shared axes between them caused some sort of "detached circular reference"
issue preventing the axes and callbacks from being garbage collected.

This does not involve closing windows, just resizing them.

Except for the part where it does: "Interestingly if I close the figures my
shell still keeps on doing stuff backstage"

Fair enough, but that is well after the bug has been triggered, I would classify that as a symptom rather than a cause.

After re-sizing zooming also does not work correctly.

This can be solved the same way as #1325

The following works as expected:

import matplotlib.pyplot as plt

fig0 = plt.figure()
a0 = fig0.add_subplot(121)
a0.set_adjustable('box-forced')
a0.imshow(p.rand(100, 100))

a1 = fig0.add_subplot(122, sharex=a0, sharey=a0)
a1.set_adjustable('box-forced')
a1.imshow(p.rand(100, 100)**2)


fig1 = plt.figure()
a2 = fig1.add_subplot(121, sharex=a0, sharey=a0)
a2.set_adjustable('box-forced')

a2.imshow(p.rand(100, 100)**3)

The key is the ax.set_adjustable('box-forced').

@tacaswell, your example above (just the first figure part) works only when the image domains are identical; for example, if you clear the second axes and then call imshow with np.random.rand(20,20), the first image will show only its 20x20 subarray.

@efiring: Should we reopen this, then?

My suspicion is that this is, as @WeatherGod suggested, a problem with sharing axes across figures. I don't think this was ever intended to be supported, and I don't think it makes sense. Therefore the fix would be to add a check to the sharex kwarg handling to ensure the two axes are in the same figure.

Even though we now have an example of sharing in different figures, the bug remains as originally described in this issue, complete with 100% CPU after closing the windows.

Regardless of how the endless loop is arising, the underlying problem is a fundamental conflict between locking together the x and y limits and the aspect ratio between axes in two figures when the figure aspect ratio is not identical. This is just one of the examples of where aspect ratio handling and sharing runs into the problem of over-specification, which is the reason I never liked the box_forced option--it only works under restrictive conditions.

I don't see that this is a problem anymore on master. I'm guessing recent work has fixed this...