[issue29270] super call in ctypes sub-class fails in 3.6
Clement Rouault added the comment: Hello, As this issue may never be fixed for python3.6. I wanted to post a solution to bypass the bug. It may be useful for the next person stumbling on this as I have. The __class__ closure is only created if a function use the word super(). This closure allow to call super() without argument. By using another name than super() the closure is not created and your code can work. Only downside is that you need to call super in its explicit form super(Cls, self). But it is better that not working at all (and it is compatible python2). Here is a sample: super_bypass_issue29270 = super class Something(ctypes.c_ulong): def __repr__(self): return "BYPASS: " + super_bypass_issue29270(Something, self).__repr__() s = Something(42) print(s) BYPASS: -- ___ Python tracker <https://bugs.python.org/issue29270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29270] super call in ctypes sub-class fails in 3.6
Clement Rouault added the comment: Hello, I have a Python2 project that relies heavily on ctypes and I cannot migrate this project to Python3 due to this bug. (I target 3.6) I have some experience with CPython and submitting patchs and I would like to know what I can do to help moving this issue forward. Thanks ! -- nosy: +hakril ___ Python tracker <https://bugs.python.org/issue29270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32725] Instance of _multiprocessing.PipeConnection-subtype crash on deletion
New submission from Clement Rouault <pyt...@hakril.net>: While playing with '_multiprocessing.PipeConnection' I found out that instancing an object with a subtype of '_multiprocessing.PipeConnection' will crash the interpreter when the object is deleted. My guess is that some connection methods does not check/handle the fact that the object is a subtype and not a 'pure' PipeConnection. I don't know if the exploitability aspect of this crash is important but it allows to rewrite an arbitrary address easily with some heap-pointer (leading to CPython trying to execute the heap). I attached a simple program that crash CPython using this bug. -- components: Library (Lib) files: poc.py messages: 311260 nosy: hakril priority: normal severity: normal status: open title: Instance of _multiprocessing.PipeConnection-subtype crash on deletion type: crash versions: Python 2.7 Added file: https://bugs.python.org/file47417/poc.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Clement Rouault added the comment: Stated as you did, it makes sens. Should the change of return type be acknowledged somewhere in the documentation ? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Clement Rouault added the comment: My comment was about the behavior of `winreg.QueryValueEx`. The current behavior is: >>> import winreg >>> tstkey = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "TestKey") >>> winreg.QueryValueEx(tstkey, "MYDWORD") # a REG_DWORD value (16909060, 4) >>> winreg.QueryValueEx(tstkey, "MYQWORD") # a REG_QWORD value (b'\x08\x07\x06\x05\x04\x03\x02\x01', 11) With this patch the new behavior would be: >>> winreg.QueryValueEx(tstkey, "MYQWORD") # a REG_QWORD value (72623859790382856, 11) I agree that exposing REG_QWORD is a new feature. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Clement Rouault added the comment: I would like to discuss the fact that this patch is a new feature. In the current state, CPython handles the `REG_QWORD` type as an unkown type and returns the raw registry value: a string of size 8. In my opinion this behavior does not match the Windows documentation (REG_QWORD: A 64-bit number) or CPython's own behavior regarding REG_DWORD that returns a Python `int` (more important). Is this enough to consider this a bugfix ? and therefore port it to 2.7 ? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Clement Rouault added the comment: Because `QWORD` is not defined in any file included by CPython. The main file for basic sized type definition in Windows is: basetsd.h: Type definitions for the basic sized types. which contains the definition of `DWORD64`: `typedef unsigned __int64 DWORD64, *PDWORD64;` but no reference to `QWORD`. Furthemore the code did not compile with the use of `QWORD`. So, I am pretty sure it is not defined by the standard includes Other people complain in your link: > "Apparently, QWORD isn't defined in any of the windows header files for MSVC 2010." Finally, the only files where I could find a typedef for `QWORD` are: * Include\shared\Sspi.h (Security Support Provider Interface. Prototypes and structure definitions) * Include\um\WinDNS.h (Domain Name System (DNS). DNS definitions and DNS API.) * Include\um\wmcodecdsp.h (COM interface -> generated code) * Include\um\wmnetsourcecreator.h (COM interface -> generated code) * Include\um\wmnetsourcecreator.idl (MIDL Interface Definition File) * Include\um\wmsdkidl.h (COM interface -> generated code) * Include\um\wmsdkidl.idl (MIDL Interface Definition File) * Include\um\mfobjects.h (COM interface -> generated code) * Include\um\Mfobjects.idl (MIDL Interface Definition File) It seems to be in pretty obscure files that should not be included by CPython (In my opinion) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Clement Rouault added the comment: I also stumbled on this issue when playing with the winreg module. I will try to make the discussion go forward by submitting a new patch. I added a test and tried everything (test included on 3.5) on my own computer (windows 8.1 64b) There are two points that might be 'sensitive' and I would like to have someone's opinion: * I am using `DWORD64` as an unsigned 64bit value as `QWORD` is not defined in * I changed one line of the previous implementation for REG_DWORD: * `PyLong_FromUnsignedLong(*(int *)retDataBuf);` became `PyLong_FromUnsignedLong(*(DWORD *)retDataBuf);` * I don't think it is a problem, but better ask than break something -- versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file42954/winreg_qword_patch_with_test.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update
Changes by Clement Rouault <pyt...@hakril.net>: -- nosy: +hakril ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: After a few months, I am back to you on this issue. What should be the next step of the process ? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: The call to PySequence_GetItem() may be expensive, and we have to drop the result if an OverflowError is raised after the call. You do realize that this error will be very rare and therefore inconsequential. The real question is: why would you call the iterator for a new value if it will be discarded anyway ? I think it could be very misleading to see _getitem__ being called and have an OverflowError being raised afterward. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment:
Also, PY_SSIZE_T_MAX is a valid value to pass to PySequence_GetItem(), so it
shouldn't be blocked unless necessary.
I agree with you, that's why my first path was checking at the next call if
it-it_index had overflowed. But then it relies on undefined behaviour.
I would think that the PY_SSIZE_T_MAX check belongs inside the:
if (result != NULL) {
it-it_index++;
return result;
}
If we raise the OverflowError when it-it_index really overflow (just after the
getitem PY_SSIZE_T_MAX).
Is it really necessary to do the overflow check after the GetItem ? because the
value returned by `PySequence_GetItem(seq, PY_SSIZE_T_MAX);` will be never used.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22939
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: Thanks for the comments. I corrected the patch and updated the test. I also added a test that check the behavior of setstate with negative indice. Just one question: __setstate__ must implement the same check. Why should __setstate__ check for PY_SSIZE_T_MAX (throwing OverflowError when unpickling) if the check will be done when calling next on the resulting iterator ? -- Added file: http://bugs.python.org/file37382/issue22939v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: Here is a first try for a patch. There are two points I am not sure about: 1) The message for the OverflowError: is that explicit enough ? 2) The behaviour of the iterator after the raise of OverflowError. With this patch every call to `next(it)` where `it` have overflowed will raise `OverflowError` again. Does this behaviour seems correct our should it raise StopIteration after the first OverflowError ? -- keywords: +patch Added file: http://bugs.python.org/file37375/issue22939.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
New submission from Clement Rouault:
I found an interger overflow in the standard iterator object
(Objects/iterobject.c)
The `it_index` attribute used by the iterator is a `Py_ssize_t` but overflow is
never checked. So after the index `PY_SSIZE_T_MAX`, the iterator object will
ask for the index `PY_SSIZE_T_MIN`.
Here is an example:
import sys
class Seq:
def __getitem__(self, item):
print([-] Asked for item at {0}.format(item))
return 0
s = Seq()
i = iter(s)
# Manually set `it_index` to PY_SSIZE_T_MAX without a loop
i.__setstate__(sys.maxsize)
next(i)
[-] Asked for item at 9223372036854775807
next(i)
[-] Asked for item at -9223372036854775808
I would be really interested in writing a patch but first I wanted to discuss
the expected behaviour and fix.
The iterator could stop after `PY_SSIZE_T_MAX` but it seems strange as other
iterator (like `enumobject`) handle values bigger than `PY_SSIZE_T_MAX`.
Or the same technique used in `enumobject` could be used: adding a field
`PyObject* en_longindex` (a python long) which would be used for values bigger
than `PY_SSIZE_T_MAX`
--
components: Interpreter Core
messages: 231651
nosy: hakril
priority: normal
severity: normal
status: open
title: integer overflow in iterator object
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22939
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21947] `Dis` module doesn't know how to disassemble generators
Clement Rouault added the comment: Updated some docstrings in the new patch after the review comments. Thanks kushou for the code review. -- Added file: http://bugs.python.org/file35954/dis_generator3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21947 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
