Jim Jewett <jimjjew...@gmail.com> added the comment: On Thu, Mar 8, 2012 at 7:43 PM, STINNER Victor wrote: > Python < 3.3 retries the lookup an unlimited number of times which > lead to a crash, that's the issue fixed by my change.
How does it lead to a crash? I think it just leads to an infinite loop (which is worse) if the data is actually malicious, but eventually fixes itself if the data is merely unlucky or even ill-behaved. Guido van Rossume: >> Can you implement the counter without adding an extra field to the dict >> object? Yes. The logic does add complexity, but there is no per-dict charge, and the extra logic can be isolated to a function that will normally not be paged in. > Add a counter requires to change the prototype of the C lookup > function: > PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash); > I don't know if it is a problem for ABI compatibility or extension > modules. I suppose that it is safer and simpler to not change it :-) That should still be the signature for the primary lookup; it can do its own delegation to a private function with an extra parameter if/when needed. > The numbers 0, 1 and infinity are special; all others are to be > treated with skepticism. Yes; it isn't clear whether to cut off after 1 retry or 3 or 10... > Is it really useful to only retry once? Retrying once means that it > would work in most cases, but not in some corner cases. For example, > retrying once may hide the problem if you have only 1 client (1 > thread), but you get the exception when you have more clients (more > threads). Without threads, there shouldn't be any problems for innocent code. Even with threads, the number of resets is not (for innocent code) tied to the number of alternative threads; only to the fact that they can run mid-lookup. -jJ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14205> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
