Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Ctrl-C in ipdb kills QtConsole on Windows #2472

dhirschfeld opened this Issue Oct 6, 2012 · 17 comments


None yet
6 participants

dhirschfeld commented Oct 6, 2012

As detailed on the user list (http://mail.scipy.org/pipermail/ipython-user/2012-October/011274.html) pressing Ctrl-C in ipdb will cause the QtConsole to hang. Tested on Windows 32bit Python with latest IPython.


takluyver commented Oct 6, 2012

One possible way to deal with this is to revert Ctrl-C to meaning 'copy' during the prompt for a raw_input() call. But there are also situations where you want to use Ctrl-C to break out of a loop of inputs.


dhirschfeld commented Oct 7, 2012

Apologies, my emails to the user list have been getting bounced. Can continue the discussion here though.

I'm not sure exactly what you mean by breaking out of a loop of inputs? On the assumption that you meant breaking out of a raw_input() by pressing Ctrl-C I tried that and it also hangs the QtConsole in the same manner as pressing Ctrl-C in ipdb.


takluyver commented Oct 7, 2012

Oh, yes, the fact that it hangs rather than breaking is certainly a bug (although I can't replicate it on Linux, as I mentioned on the mailing list).

I was thinking of another comment you made, that you expect Ctrl-C to copy. We try to be smart about that, but obviously IPython isn't psychic.


dhirschfeld commented Oct 8, 2012

I can see that there's conflicting requirements here and probably no perfect solution. From my own experience I think your suggestion of having Ctrl-C copy whilst at the prompt would be an improvement, but I'd be fine if it worked as on Linux, just kicking you out of the debug session.

If any of the IPython devs would like an Azure VM to test on I can probably sort one out - just let me know.


takluyver commented Oct 8, 2012

Thanks Dave. I think we can mostly get access to Windows to test on, but most of us don't use Windows day-to-day. @jstenar is often the one who does Windows fixes.


jstenar commented Oct 8, 2012

Unfortunately my Qt knowledge is nonexistent and I have no idea where to
start debugging this. My first thought whenever I see a problem with
ctrl-c on windows is setuptools' problems with the script exe files. I
verified this bug by launching qtconsole from the ipython-script.py file
and not ipython.exe, so it seems this is not related to setuptools.


takluyver commented Oct 8, 2012

If you set something that's not an input prompt going (time.sleep(10)), can you interrupt it with Ctrl-C in the Qt console?


dhirschfeld commented Oct 8, 2012

Ctrl-C doesn't interrupt time.sleep for me although it seems to keep the Ctrl-C in a buffer such that a KeyboardInterrupt is thrown immediately after time.sleep returns - i.e.

In [16]: try:
    ...:     print 'Entering sleep @', time.ctime()
    ...:     time.sleep(15) # Pressed Ctrl-C here
    ...:     print 'Exited sleep @', time.ctime()
    ...: except KeyboardInterrupt:
    ...:     print 'KeyboardInterrupt raised @', time.ctime()
Entering sleep @ Mon Oct 08 20:40:02 2012
Ctrl-C pressed
KeyboardInterrupt raised @ Mon Oct 08 20:40:17 2012

In [17]: 

takluyver commented Oct 8, 2012

And just to check, if you Ctrl-C in a terminal session with Python, you can
interrupt something? Maybe it's about how the interrupt signal is sent or

(I say Ctrl-C, but it might be something like ctrl+break on Windows)


dhirschfeld commented Oct 9, 2012

In the terminal Ctrl-C in the debugger will simply exit the debugging session and Ctrl-C in a time.sleep will immediately exit the sleep.

However Ctrl-C at any time, anywhere in the terminal IPython (on Windows) will kill the IPython session. By kill I mean that it will return you what looks like an IPython prompt but anything you type gets executed in the terminal rather than IPython before returning you back to an apparent IPython prompt - e.g.

In [10]: try:
   ....:     print 'Entering sleep @', time.ctime()
   ....:     time.sleep(15) # Pressed Ctrl-C here
   ....:     print 'Exited sleep @', time.ctime()
   ....: except KeyboardInterrupt:
   ....:     print 'KeyboardInterrupt raised @', time.ctime()
Entering sleep @ Tue Oct 09 09:24:40 2012
KeyboardInterrupt raised @ Tue Oct 09 09:24:42 2012
In [11]: x = 10
'x' is not recognized as an internal or external command,
operable program or batch file.

In [11]:

Ctrl-Break will immediately exit the terminal IPython session without prompting but has no effect in the QtConsole.


takluyver commented Oct 9, 2012

I wonder if that's the setuptools bug @jstenar mentioned. Can you try starting IPython using ipython-script.py? Also, how does Ctrl-C behave at a plain Python prompt (not IPython)?


dhirschfeld commented Oct 9, 2012

Wow, that's nasty! I can confirm that when started with ipython-script.py the terminal IPython behaves as expected - i.e. Ctrl-C will drop you out of the debugger (to a working IPython prompt) and will interrupt a time.sleep call.

A plain python interpreter it behaves much as the terminal IPython i.e. it will break out of a time.sleep call and will also break out of the pdb debugger.

So it seems to just be an issue in the QtConsole.

@szrw668 szrw668 referenced this issue in gotcha/ipdb Jan 19, 2013


ipdb got stuck with copy #36


joonro commented Jun 2, 2013

I'm having this issue as well - in QT console windows. When I do post-mortem debugging, pressing ctrl+c hangs qt console. (IPython 13.2 with Anaconda 64bit in Windows 8)


ivanov commented Jun 17, 2014

@dhirschfeld @joonro is this still an issue in QtConsole? there's been no activity here for a while


ivanov commented Jun 17, 2014

Marking as needs-info so on a future pass (in a month?) we can close this if there's no activity


dhirschfeld commented Aug 5, 2014

Hi @ivanov, I'm still seeing this problem in IPython 2.1. Won't be able to check master for another week as I'm on holiday. It's still a huge problem for Windows QtConsole/Spyder users as it makes debugging extremely painful.

I tried to debug myself but got nowhere. IIRC I traced the signal handler down to a Qt call where it got swallowed (my memory could be hazy though as it was nearly a couple of years ago now). I haven't followed up because I don't think the situation has changed - I don't have the skills to debug and since IIUC none of the core developers use windows or are Qt experts it's not been an itch anyone has felt like scratching. We've "worked-around" the problem by using PyCharm for serious debugging and training ourselves to never use the Ctrl-C to copy!

I can post a followup with any further info that would help when I'm in the office next week...

@takluyver takluyver added this to the not ipython milestone Jan 26, 2016


Carreau commented Jul 20, 2017

Closing as this issue is not in IPython itself and if still problematic and relevant should be opened on the right repository. This will allow to keep the number of opened issue on the IPython repo under control.

Feel free to keep commenting or reopen if necessary.


@Carreau Carreau closed this Jul 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment