STINNER Victor <victor.stin...@gmail.com> added the comment:
> (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).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14091>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
