This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author telmich
Recipients telmich
Date 2012-03-08.09:05:34
SpamBayes Score 2.74402e-10
Marked as misclassified No
Message-id <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
In-reply-to
Content
Hello,

pressing ctrl-c or having sigint delivered to the python process in its startup phase results in random tracebacks displayed.

This is related to issue3137, but actually happening in Python 3.2.2 on archlinux.

We noticed this during development of the cdist project (http://www.nico.schottelius.org/software/cdist/), where we call a shell via subprocess.check_call() which calls us again (under a different name and thus different behaviour.

So the call chain is like this:

cdist => /bin/sh -e script => cdist_as_different_name (i.e. __file)

A simple test case to reproduce the problem needs the two files caller.py and shellpart.sh in a directory:

% ln -s caller.py __testpython
% chmod a+x *
% ./caller.py                 
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
^Ccaught signint in parent
Traceback (most recent call last):
  File "/usr/lib/python3.2/site.py", line 58, in <module>
    import traceback
  File "/usr/lib/python3.2/traceback.py", line 3, in <module>
    import linecache
  File "/usr/lib/python3.2/linecache.py", line 10, in <module>
    import tokenize
  File "/usr/lib/python3.2/tokenize.py", line 28, in <module>
    import re                                                                                                         
  File "/usr/lib/python3.2/re.py", line 121, in <module>
[10:02] brief:python-traceback-test%     import functools
  File "/usr/lib/python3.2/functools.py", line 2, in <module>
    """
KeyboardInterrupt


Pressing Ctrl-C results in various different tracebacks and I don't see any way to catch the SIGINT reliably currently, as the code executed seems to be *before* my code is being executed.

There is another related bug at debian that references the same problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926
History
Date User Action Args
2012-03-08 09:05:37telmichsetrecipients: + telmich
2012-03-08 09:05:36telmichsetmessageid: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
2012-03-08 09:05:36telmichlinkissue14228 messages
2012-03-08 09:05:34telmichcreate