[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
New submission from Zygmunt Krynicki: It seems that a particular code sequence causes memory corruption (but not a crash so far) in the interpreter. I've attached a test case that fails assertion on python3.2 (tested on current amd64 12.04 builds) and works on python3.3 (tested on current amd64 14.04 builds and i386 fedora 19 builds). The attached test program shows how the bug is actually triggered by using a for loop to iterate over key, value in namespace.items() inside a metaclass __new__() method that does nothing else apart from that. -- components: Interpreter Core files: bug.py messages: 205250 nosy: zkrynicki priority: normal severity: normal status: open title: possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__ type: security versions: Python 3.2 Added file: http://bugs.python.org/file32975/bug.py ___ Python tracker <http://bugs.python.org/issue19888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
Zygmunt Krynicki added the comment: 2.7 test program -- Added file: http://bugs.python.org/file32976/issue-19888.py27.py ___ Python tracker <http://bugs.python.org/issue19888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
Zygmunt Krynicki added the comment: Experimenting with a few modifications lead to the following observations: 1) objects with short names (defined inside the Obj class) tend to be ignored and don't trigger the bug 2) Longer names tend to trigger the bug, ordering is not deterministic 3) Calling __new__ before iterating over namespace makes the problem go away, it seems to be related to the for loop more than to anything else -- ___ Python tracker <http://bugs.python.org/issue19888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
Zygmunt Krynicki added the comment: This is not a bug, name spills out of for ... loop and then gets passed to __new__ -- ___ Python tracker <http://bugs.python.org/issue19888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
Changes by Zygmunt Krynicki : -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue19888> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
Changes by Zygmunt Krynicki : -- title: unittest.mock.MagicMock doesn't support __rdivmod__t -> unittest.mock.MagicMock doesn't support __rdivmod__ ___ Python tracker <http://bugs.python.org/issue23568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__t
New submission from Zygmunt Krynicki: Hey. I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library. The bug I'd like to report now is that __rdivmod__ cannot be mocked by MagicMock. This seems to be caused by the fact that it is listed as magic but not as numeric (for which right-hand-side variants are created). Note that it cannot be simply added to numeric as it doesn't have the augmented assignment variant (there is no __idivmod__). The bug is present in all versions of Python that come with unittest.mock (3.3, 3.4 and 3.5) and it is also present in the upstream/standalone version of mock -- components: Library (Lib) messages: 237112 nosy: zkrynicki priority: normal severity: normal status: open title: unittest.mock.MagicMock doesn't support __rdivmod__t versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23569] unittest.mock.MagicMock.__div__ works but __truediv__ doesn't (3.3 only)
New submission from Zygmunt Krynicki: Hey. I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library. The bug I'd like to report now is that __truemod__ cannot be mocked by MagicMock but __div__ can (despite __div__ being gone from Python 3 entirely). This bug is specific to Python 3.3 and it is fixed in 3.4 and 3.5a1 -- messages: 237113 nosy: zkrynicki priority: normal severity: normal status: open title: unittest.mock.MagicMock.__div__ works but __truediv__ doesn't (3.3 only) type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue23569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
Changes by Zygmunt Krynicki : -- type: -> behavior versions: +Python 3.3 -Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23581] unittest.mock.MagicMock doesn't support matmul (@) operator
New submission from Zygmunt Krynicki: Hi. I'm the upstream of Padme, a mostly transparent proxy library for Python. I was adding support for the new matmul/@ operator when I noticed that MagicMock doens't support it yet. >>> form unittest.mock import MagicMock >>> MagicMock() @ 1 Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for @: 'MagicMock' and 'int' To add support simply add 'matmul' to unittest.mock.numerics. -- components: Library (Lib) messages: 237176 nosy: zkrynicki priority: normal severity: normal status: open title: unittest.mock.MagicMock doesn't support matmul (@) operator type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue23581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
