New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dictobject infinite loop in module set-up #59108
Comments
I seem to be encountering somewhat rare an infinite loop #0 0x08088637 in lookdict_string (mp=0xa042714, key='SO_RCVTIMEO',
hash=612808203) at ../Objects/dictobject.c:421
#1 0x080886cd in insertdict (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203,
value=20) at ../Objects/dictobject.c:450
#2 0x08088cac in PyDict_SetItem (op=<unknown at remote 0x37>, key=
'SO_RCVTIMEO', value=20) at ../Objects/dictobject.c:701
#3 0x0808b8d4 in PyDict_SetItemString (v=
{'AF_INET6': 10, 'SocketType': <type at remote 0x8275e00>,
'getaddrinfo': <built-in function getaddrinfo>,
'TIPC_MEDIUM_IMPORTANCE': 1, 'htonl': <built-in function htonl>,
'AF_UNSPEC': 0, 'TIPC_DEST_DROPPABLE': 129, 'TIPC_ADDR_ID': 3,
'PF_PACKET': 17, 'AF_WANPIPE': 25, 'PACKET_OTHERHOST': 3, 'AF_AX25':
3, 'PACKET_BROADCAST': 1, 'PACKET_FASTROUTE': 6, 'TIPC_NODE_SCOPE': 3,
'inet_pton': <built-in function inet_pton>, 'AF_ATMPVC': 8,
'NETLINK_IP6_FW': 13, 'NETLINK_ROUTE': 0, 'TIPC_PUBLISHED': 1,
'TIPC_WITHDRAWN': 2, 'AF_ECONET': 19, 'AF_LLC': 26, '__name__':
'_socket', 'AF_NETROM': 6, 'SOCK_RDM': 4, 'AF_IRDA': 23, 'htons':
<built-in function htons>, 'SOCK_RAW': 3, 'inet_ntoa': <built-in
function inet_ntoa>, 'AF_NETBEUI': 13, 'AF_NETLINK': 16,
'TIPC_WAIT_FOREVER': -1, 'AF_UNIX': 1, 'TIPC_SUB_PORTS': 1,
'HCI_TIME_STAMP': 3, 'gethostbyname_ex': <built-in function
gethostbyname_ex>, 'SO_RCVBUF': 8, 'AF_APPLETALK': 5,
'SOCK_SEQPACKET': 5, 'AF_DECnet': 12, 'PACKET_OUTGOING': 4,
'SO_SNDLOWAT': 19, 'TIPC_SRC_DROPPABLE':...(truncated), key=0x81ac5fb
"SO_RCVTIMEO", item=20) at ../Objects/dictobject.c:2301
#4 0x080f6c98 in PyModule_AddObject (m=<module at remote 0xb73cac8c>, name=
0x81ac5fb "SO_RCVTIMEO", o=20) at ../Python/modsupport.c:615
#5 0x080f6d0b in PyModule_AddIntConstant (m=<module at remote 0xb73cac8c>,
name=0x81ac5fb "SO_RCVTIMEO", value=20) at ../Python/modsupport.c:627
#6 0x081321fd in init_socket () at ../Modules/socketmodule.c:4708 Here, we never escape from lookdict_string. The key is not in the $3 = {ob_refcnt = 1, ob_type = 0x81c3aa0, ma_fill = 128, ma_used = 128, The Python program that is running afoul this bug is using gevent, but Finally, what's especially strange is that I had gone a very long time |
Can you reproduce on current 2.7.3 or 3.2.3 or even 3.3.0 (which has changed dict implementation)? Or can you upload a short program that exhibits the problem, so someone else can try? 2.6 gets security fixes only and I do not believe this qualifies. If not a current problem, this should be closed as out of date, even if disconcerting. |
Unfortunately it's not so easy to upgrade the system's Python, however, it is something we might try. The reproducing test case would appear to be akin to: "import _socket" And, within the gevent stack trace program, https://github.com/schmir/gevent/blob/master/gevent/monkey.py#L109 But to be precise, it is stuck at: https://github.com/heroku/WAL-E/blob/master/wal_e/cmd.py#L17. None of this is very helpful, I realize, but this program (in this case, when archiving PostgreSQL write-ahead-log archives) is started up millions of times in a day, putting the defect rate at not far from the nominally figurative phrase "one in a million". |
I was suggesting alternate installations, not that you touch your system Python (a bad idea I have read). Such should be easy on Ubuntu. Whether you can run this particular program with alt installs is a different matter. If you have questions about doing so, also try python-ideas list or the news.gmane mirror, where there are several *nix users, including Ubuntu. |
Hello folks, After long delay, I can confirm this issue reproduces in a similar way inside of init_socket in 2.7. |
In addition to being re-verified on 2.7, this occurred on a 64 bit system, so I've changed the title accordingly. |
I've confirmed this in a non-gevent program (actually a very trivial one, I can include the source if anyone asks), in 'initposix'. This is on a quiet system, so OOM is not a very likely explanation. Perhaps signal handling? #0 0x000000000054662d in ?? () |
If you could supply the source that'd be great. |
Attached. The program's function is to take a base64 encoded string and arguments as input and then to materialize this program on disk and run it with its arguments. Notably, this one contains no socket interaction at all, unlike the other examples, which narrows the cause quite a bit. It is run via 'ssh'. Like the other case, it's during module dictionary set-up. |
altered title now that it's been seen in init_posix. |
Can you provide specific details of exactly which python package from which distro is installed on the machines? Are the machines hardware or VMs? if they are VMs, what version of what VM system and what hardware are the VMs running on? I'm asking because someone at work is seeing a potentially similar problem from an ubuntu python2.7-minimal package - i don't know which version - they can pipe in here and provide that and any other details that may be relevant. |
I reproduced the problem with Python 2.7.5 as shipped with CentOS 7: root@192.168.0.86 /home/padmin # python -V (gdb) bt The infinite loop happens when "import rpm" is called in low-memory conditions (e.g. when handling ENOMEM or exceptions.MemoryError - RedHat/CentOS abrt-addon-python package which installs sys.excepthook handler). |
Is this a python 2-only issue? |
I suspect so. If any modern supported python 3.x version runs into an issue like this I think opening a fresh bugreport is good. Closing as not reproducable / obsolete. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: