homepage

Here is the behavior I am getting only on Python 2.7.2 in a Fedora 16:
$ cat /tmp/example.py
from subprocess import Popen,PIPE
args = "whatever program".split()
p = Popen(args)
If I run the program with:
$ cd /tmp/; python example.py
I get following as expected
Traceback (most recent call last):
 File "example.py", line 7, in <module>
 p = Popen(args)
 File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
 errread, errwrite)
 File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
 raise child_exception
OSError: [Errno 2] No such file or directory
Instead if I run the program with:
$ cd ~; python /tmp/example.py
It hangs until I stop it with ctrl-c
On the same machine python 3.2.1 works fine.
On a mac with python 2.7.1 works fine.
On a rhel5 with python 2.4 works fine too.

I'm unable to reproduce the problem on Fedora 16 with Python 2.7.2.
> It hangs until I stop it with ctrl-c
Do you get an exception after hiting CTRL+c?

Yes, the expected one:
^CTraceback (most recent call last):
 File "/tmp/example.py", line 7, in <module>
 p = Popen(args)
 File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
 errread, errwrite)
 File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
 raise child_exception
OSError: [Errno 2] No such file or directory

The line which is mentioned in the exception for the file example.py is 7 because I have something commented out which I didn't past in the text before.

Could you try to collect more information with gdb?
cd ~; gdb -args python /tmp/example.py
(gdb) run
<python hangs>
CTRL+c
(gdb) where
<the expected output>

$ cd ~; gdb -args python /tmp/example.py
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.7.2-5.2.fc16.x86_64
(gdb) run
Starting program: /usr/bin/python /tmp/example.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 16202.
^C
Program received signal SIGINT, Interrupt.
0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
(gdb) where
#0 0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
#1 0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#2 0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#3 0x00000039d6ae00bd in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#4 0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#5 0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#6 0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7 0x00007ffff0755597 in ?? () from /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
#8 0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#9 0x00000039d6ade795 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#11 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#12 0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#13 0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#14 0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#15 0x00000039d6ada457 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#16 0x00000039d6afcdde in PyErr_PrintEx () from /usr/lib64/libpython2.7.so.1.0
#17 0x00000039d6afd38e in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#18 0x00000039d6b0e745 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#19 0x00000039d362169d in __libc_start_main () from /lib64/libc.so.6
#20 0x0000000000400651 in _start ()
(gdb)

> (gdb) where
> #0 0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
> #1 0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
> #2 0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
Hum, it's something related to network. Fedora uses its ABRT program
to catch program failures.
/usr/lib/python2.7/site-packages/abrt.pth contains "import
abrt_exception_handler" which install a custom sys.excepthook. This
hook writes a report and send it to the UNIX socket
/var/run/abrt/abrt.socket.
In your example, it looks like the abrt daemon is dead or at least
doesn't not answer, and so the abrt "client" hangs on the connection
to the UNIX socket. You may try to add a timeout to
s.connect("/var/run" + "/abrt/abrt.socket") in write_dump() of the
abrt_exception_handler module. You should also report the bug to
Fedora because it's unrelated to Python (core).

Will follow it.
Thanks,
-Massimo

> Will follow it.
If you report the issue to abrt, could you give me the url to your report please? (as a comment to this issue)