[issue14205] Raise an error if a dict is modified during a lookup

Roundup Robot added the comment: New changeset 93748e2d64e3 by Antoine Pitrou in branch 'default': Issue #14417: Mutating a dict during lookup now restarts the lookup instead of raising a RuntimeError (undoes issue #14205). http://hg.python.org/cpython/rev/93748e2d64e3 --

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: Was the crasher ever converted into a unittest? I think that should be done regardless of the outcome of the ongoing discussion about this issue. -- ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

Jim Jewett added the comment: See http://bugs.python.org/issue14417 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue14205] Raise an error if a dict is modified during a lookup

Roundup Robot added the comment: New changeset 70fbb02d588c by Victor Stinner in branch 'default': Issue #14205: Fix test_dict.test_mutating_lookup() http://hg.python.org/cpython/rev/70fbb02d588c -- ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

Mark Shannon added the comment: STINNER Victor wrote: > STINNER Victor added the comment: > > Guido> Given all this I think we should keep it as you have committed > Guido> and add it to the docs and whatsnew. > > I updated What's New in Python 3.3 document. I also wrote an email to > python

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: Guido> Given all this I think we should keep it as you have committed Guido> and add it to the docs and whatsnew. I updated What's New in Python 3.3 document. I also wrote an email to python-dev to notify all developers of this change. Let's close the issue.

[issue14205] Raise an error if a dict is modified during a lookup

Roundup Robot added the comment: New changeset a428f85de29c by Victor Stinner in branch 'default': Issue #14205: Document the dict lookup change in What's New in Python 3.3 http://hg.python.org/cpython/rev/a428f85de29c -- ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: > Unmodified CPython (without the patch) already passes the new test in the > patch. You should try Lib/test/crashers/nasty_eq_vs_dict.py, not my test. -- ___ Python tracker ___

[issue14205] Raise an error if a dict is modified during a lookup

Mark Shannon added the comment: Unmodified CPython (without the patch) already passes the new test in the patch. The unmodified code already raises a Runtime error; a recursion limit exceeded error! -- ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

Jim Jewett 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 wors

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: On Thu, Mar 8, 2012 at 4:56 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> Can you implement the counter without adding an extra field to the dict >> object? > > Add a counter requires to change the prototype of the C lookup function:

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: > Can you implement the counter without adding an extra field to the dict > object? 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 pr

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: I'm still torn. Can you implement the counter without adding an extra field to the dict object? I worry that we'll get the same objection we had when MAL proposed collision counting as a solution to the hash DoS attack. The numbers 0, 1 and infinity are s

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: Guido: So, what do you think? Do you like the new behaviour, or would you prefer a softer solution like retrying N times? Python < 3.3 retries the lookup an unlimited number of times which lead to a crash, that's the issue fixed by my change. -- ___

[issue14205] Raise an error if a dict is modified during a lookup

Roundup Robot added the comment: New changeset 0255bafbccf2 by Victor Stinner in branch 'default': Issue #14205: document the change of dict[key] behaviour if dict is modified http://hg.python.org/cpython/rev/0255bafbccf2 -- ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue14205] Raise an error if a dict is modified during a lookup

Jim Jewett added the comment: On Tue, Mar 6, 2012 at 1:05 PM, Guido van Rossum Jim Jewett: >>...  If they're just adding new keys, or even deleting other >> (==> NOT the one being looked up) keys, why should that >> keep them from finding the existing, unchanged keys? >> ... The chain terminat

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: On Tue, Mar 6, 2012 at 9:43 AM, Jim Jewett wrote: > > Jim Jewett added the comment: > > On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote: > >> Jim Jewett: >>> Can't this be triggered by non-malicious code that just happened >>> to have a python comparison

[issue14205] Raise an error if a dict is modified during a lookup

Jim Jewett added the comment: On Tue, Mar 6, 2012 at 11:56 AM, Mark Shannon wrote: > Jim Jewett: >> Can't this be triggered by non-malicious code that just happened >> to have a python comparison and get hit with a thread switch? > So, they are writing to a dict in one thread while reading fro

[issue14205] Raise an error if a dict is modified during a lookup

Changes by STINNER Victor : -- resolution: fixed -> status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: On Tue, Mar 6, 2012 at 8:56 AM, Mark Shannon wrote: > > Mark Shannon added the comment: > > Jim Jewett wrote: >> Jim Jewett added the comment: >> >> Can't this be triggered by non-malicious code that just happened to have a >> python comparison and get hit

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: > If the __eq__ method of the > objects used for keys use C functions releasing the GIL, you may > trigger the issue. Oh, I mean: trigger the issue with threads. I hope that your objects don't call C functions like open() in their __eq__() method! --

[issue14205] Raise an error if a dict is modified during a lookup

Mark Shannon added the comment: Jim Jewett wrote: > Jim Jewett added the comment: > > Can't this be triggered by non-malicious code that just happened to have a > python comparison and get hit with a thread switch? So, they are writing to a dict in one thread while reading from the same dict

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: > Can't this be triggered by non-malicious code that just happened to have a > python comparison and get hit with a thread switch? The issue was triggered without threads.If the __eq__ method of the objects used for keys use C functions releasing the GIL, you

[issue14205] Raise an error if a dict is modified during a lookup

Jim Jewett added the comment: Can't this be triggered by non-malicious code that just happened to have a python comparison and get hit with a thread switch? I'm not sure how often it happens, but today it would not be visible to the user; after the patch, users will see a sporadic failure tha

[issue14205] Raise an error if a dict is modified during a lookup

Roundup Robot added the comment: New changeset 934aaf2191d0 by Victor Stinner in branch 'default': Close #14205: dict lookup raises a RuntimeError if the dict is modified during http://hg.python.org/cpython/rev/934aaf2191d0 -- nosy: +python-dev resolution: -> fixed stage: -> committed

[issue14205] Raise an error if a dict is modified during a lookup

Guido van Rossum added the comment: Yeah, dict_lookup.patch seems fine. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue14205] Raise an error if a dict is modified during a lookup

Changes by Raymond Hettinger : -- assignee: -> rhettinger priority: normal -> low ___ Python tracker ___ ___ Python-bugs-list mailing

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: > I much prefer dict_lookup.patch to nomodify.patch. > It doesn't increase the memory use of dict. One extra word > per dict could be a lot of memory for a large application. nomodify.patch is the correct fix, but I agree that dict_lookup.patch is better (and

[issue14205] Raise an error if a dict is modified during a lookup

Mark Shannon added the comment: I much prefer dict_lookup.patch to nomodify.patch. It doesn't increase the memory use of dict. One extra word per dict could be a lot of memory for a large application. There is a very subtle semantic change, but I think it is a positive one. Raising a runtimne

[issue14205] Raise an error if a dict is modified during a lookup

Changes by Antoine Pitrou : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue14205] Raise an error if a dict is modified during a lookup

STINNER Victor added the comment: Another possibility is to avoid the modification of a dictionary during a lookup: nomodify.patch. -- Added file: http://bugs.python.org/file24741/nomodify.patch ___ Python tracker

[issue14205] Raise an error if a dict is modified during a lookup

New submission from STINNER Victor : Lib/test/crashers/nasty_eq_vs_dict.py does crash Python because of an infinite loop in the dictionary lookup. The script modifies the dictionary at each lookup, whereas Python tries a new lookup each time that the dictionary is modified. I proposed to make th