Skip to content

show() blocks in pylab mode with ipython 0.10.1 #185

lebedov opened this Issue Oct 25, 2010 · 17 comments

5 participants

lebedov commented Oct 25, 2010

After updating to ipython 0.10.1 on 64-bit Linux, I noticed that plotting commands no longer automatically display anything when ipython is started with the -pylab option. Moreover, the show() command now appears to block in pylab mode. I don't have any local ~/.matplotlib/matplotlibrc file installed.

IPython member
fperez commented Oct 25, 2010

Ouch, it seems we have a nasty regression with GTK, which happens to be the default on linux. Could you try starting it with

ipython --pylab --qthread


ipython --pylab --q4thread

To use Wx or Qt instead? Let us know how that goes, and if it works OK, it may be a necessary workaround until we find/fix the bug.

lebedov commented Oct 25, 2010

Wx and Qt/Qt4 work fine.

IPython member
fperez commented Oct 25, 2010

OK, thanks for the report. We'll try to fix the gtk bug as soon as possible, though. In the meantime, wx/qt will have to be the workaround.

lebedov commented Oct 25, 2010

Thanks, Fernando!


Took a quick look at this.
If I check out the 0.10.2 branch and invoke: ipython --pylab --gthread
it hangs.
Reverting commits
3e84e9f (most recent commit to muck with GTK in and
dfb0d60 (which applies on top of the previous commit)
appears to fix the hanging problem.


My gtkfix branch ( is 0.10.2 with
the above reversions, if anyone wants to try it.

Confirmed that "ipython --pylab --gthread" hangs prior to reverting 3e84e9f, but that
after reverting "ipython --pylab --gthread" works, "plot(rand(100))" works without
hanging, and "show()" also does not hang.

IPython member
ivanov commented Oct 26, 2010

Keeping simple things simple - I can confirm that:
$ ipython -pylab -gthread
In [1]: ax = subplot(111); ax.plot(rand(10)); show()
all work, without blocking with just one line change to the current 0.10.2 branch, by uncommenting gtk.set_interactive(False) after gtk is imported on line 781 of


I updated to the 10.2 git branch just now, and while "ipython -pylab -gthread" leads to a working interpreter, "ipython -pylab" (no -gthread argument) exhibits the same problems described in the bug description.

IPython member
fperez commented Oct 31, 2010

Mmh, I see that. It's very odd, but thanks for pointing it out. I'll investigate further before pushing 0.10.2 out.

lebedov commented Dec 23, 2010

Any word on when 0.10.2 will be released?

IPython member
fperez commented Dec 28, 2010

Unfortunately I'm swamped and will remain so for the next 3-4 weeks. The issue is that even in the 0.10.2 branch as it stands now, the regression isn't fixed. Non-gtk backends work OK, but the gtk one remains borked, and if nobody submits a pull request with a good fix for it, I'll need some time to work on restoring the functionality myself.

So likely 3 weeks at best, I'm afraid. Lack of manpower sucks...

The best way to help would be for someone to provide a pull request against 0.10.2 that fully fixes this, and then I could quickly cut a release.


I should have time to hack on this tomorrow night, but I'm having a bit of trouble
reproducing the bug. If I check out 42cb9 (the 0.10.2 branch from 10/12) I can
reproduce the "ipython --pylab --gthread" freeze. If I check out 8ed54 (Paul's fix),
81615 (Fernando's additional check_gtk calls), or 972dc (most recent 0.10.2 commit)
and test with:

ipython --pylab
ax = subplot(111); ax.plot(rand(10)); show()

I don't see blocking. (This is on Ubuntu Lucid with up-to-date matplotlib)

Fernando or Drew, is there a better test case that I should be using?
(If not, I'll double check that I'm getting a clean rebuild of IPython after my checkouts)

IPython member
ivanov commented Dec 29, 2010

The original issue was created by a portion of commit 3e84e9f which I'll refer to as "problematic commit".

My fix185 branch originally undid a portion of the problematic commit, and the outstanding issue relates to other portions of that same commit.

What isn't clear to me is the purpose of the function check_gtk inside, which was added in the problematic commit. For some reason, it unconditionally returns mode 'tkthread' if gtk was safely imported and hasattr 'set_interactive', regardless of what mode was passed to it. This "functionality" is not used with the -pylab flag, which is why original one line change did not fix the issue for "ipython -gthread"

I added another commit to the fix185 branch which removes check_gtk() altogether, and see no issues using ipython -gthread, ipython -gthread -pylab, or ipython -pylab. Additionally, the check_gtk() imported gtk regardless of what mode the user selected, and might also be what's been causing the "Why is IPython using X11" threads on the mailing list.

also, I just want to note here that users will see this issue if they use e.g "ipython -gthread" but their matplotlib is set to some other backend by default (say "WX").

I opened pull request #237 to get this into 0.10.2 branch

IPython member
ivanov commented Dec 29, 2010

mark: d'oh - we keep getting into race conditions with one another! :)

can you test the latest in my fix185 branch with:

ipython -gthread

the ipython -pylab -gthread were taken care of by the earlier fix, the -gthread without -pylab and just -pylab was actually problematic for me. Make sure that your matplotlib is using backend GTK when you do your test. I tested with

import matplotlib.pyplot as plt
'GTK' in plt.get_backend()


Paul: Ah, my bad, I was testing with the TkAgg backend.

With the GTK backend and current fix185 (7fb20b) "ipython --gthread" runs Paul's test
without blocking (with the TkAgg backend, blocks until the plot window is
closed). For this commit, "ipython --pylab" and "ipython --pylab --gthread" can
plot without blocking for both the GTK and TkAgg backends.
(dumping more complete test results in Paul's pull request)

IPython member
fperez commented Feb 14, 2011

Note: this old bug in LP

actually has useful info and the attached script by Ville seems to work well.

I'll try to take care of this in the next few days so we can finally get 0.10.2 out the door and fix the gtk brokenness.

IPython member
fperez commented Mar 13, 2011

Actually, now that we've merged all of Paul's pull requests, I think we're finally back to normal for GTK on 0.10.2.

Many thanks to everyone for the help with this! I'll close this now, please reopen if anybody notices any problems still with 0.10.2.

@jedludlow jedludlow pushed a commit that referenced this issue Dec 19, 2012
@ivanov ivanov remove set_interactive gtk check (fix #185)
It was unclear why the function check_gtk() was added in the first
place, but blocked when using "ipython -gthread" without
the "-pylab"

also, I just want to note here that users will still experience blocking
behaviour if they use e.g "ipython -gthread" but their matplotlib is set
to some other backend by default (say "WX").
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.