[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer
Michael Curran added the comment: PR: https://github.com/python/cpython/pull/26204 Looks like a maintainer needs to allow a workflow to run for the remaining checks. -- ___ Python tracker <https://bugs.python.org/issue38748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer
Michael Curran added the comment: As requested, I created a pr which adds a test to show the crash. It is marked as expected failure on 32 bit (x86) and runs successfully as expected on x64. What would be the next steps in moving this issue forward? I don't think I have the knowledge to be able to start on an actual fix for the bug myself, but I and my organization are happy to assist where we can. A little bit of background: The NvDA screen reading software allows blind and vision impaired people across the globe to access the Windows Operating System independently, improving socialization, education and employment outcomes. It is used by around 200,000 people in over 150 countries. The NVDA screen reader is written primarily in Python, and is currently using Python 3.7. We would like to upgrade to a newer Python release, but currently cannot due to this bug. We currently use the x86 build of Python as a small (but significant) number of our users are still on a pure 32-bit build of Windows. Taking into account the fact that are main demographic are people from developing countries, it is not simple for many of our users to upgrade their existing hardware to 64-bit. There will come a time where we will drop x86 support, and just release an x64 build of NVDA, but right now our pure x86 user numbers are still too high. We would love to be able to get our 200,000 users onto a more recent and secure Python version as soon as possible, but we can only do this once this bug is addressed. This bug has now been open for 2 years. If the bug is impossible to fix, or no one is able, then perhaps Python needs to consider dropping support for x86, as currently this build can cause stack corruption, as demonstrated by this issue and the pr tests. -- ___ Python tracker <https://bugs.python.org/issue38748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer
Michael Curran added the comment: This bug is reproduceable on both Python 3.8 and 3.9. But not 3.7. Ths bug is seen in the real world, in the context of providing Python callbacks to Win32 API functions, or when implementing comtypes COM objects in Python. For example, we see this crash in the NVDA screen reader project, in our implementation of ITTSBufNotifySink from the Microsoft SAPI4 speech API. ITTSBufNotifySink::TextDataStarted takes a pointer (this), and a long long (qTimestamp). https://github.com/nvaccess/nvda/issues/12152 -- ___ Python tracker <https://bugs.python.org/issue38748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer
Michael Curran added the comment: I can also reproduce this. I will attach my own testcase below. So far I see it when the callback is __stdcall (WINFUNCTYPE) and it takes an larger than 4 bytes (E.g. a long long or a VARIANT), with one or more arguments preceeding it such that this argument is not aligned on a multiple of 8 bytes. For example arguments can be: * long, long long * long, long, long, long long But the corruption does not occur with something like: * long, long, long long My testcase uses long, long long to show the crash. -- nosy: +michaeldcurran Added file: https://bugs.python.org/file49959/py3.8crash.zip ___ Python tracker <https://bugs.python.org/issue38748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
Michael Curran m...@nvaccess.org added the comment: Tested on Windows 7 x64, with Python 2.7 rc1 [amd64]: both examples work fine. So it seems the issue is specific to x86. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
New submission from Michael Curran m...@nvaccess.org: There seem to be problems with WINFUNCTYPE callbacks causing exceptions, and or getting their return value ignored by the caller, when using Python 2.7 rc1. Two examples provided. Example 1: Providing a WINFUNCTYPE wrapped python function when calling EnumWindows from user32.dll with ctypes, EnumWindows enumerates (calls the python function) for the first 5 windows and then causes a WindowsError, sometimes an access violation (reading, or writing), or even other strange unknown exceptions. This specific testcase is attached to the bug. Run this script in Python 2.7 you should see the WindowsErrors. On Python 2.6 it successfully enumerates through all windows. Example 2: Hooking low-level keyboard input in Windows with SetWindowsHookEx from user32.dll, providing a WINFUNCTYPE wrapped python function as the callback, and then typing some keys, causes the callback to be called but the return value is always ignored, which means the hook never blocks keys completely, even if the value 1 is returned from the callback, to do so. Again, a testcase is attached to the bug. Run this script in Python. It will ask you to type some characters and press enter. On Python 2.6 no characters should be echoed to the screen, but you will hear beeps to let you know the keyboard hook is seeing the keys. On Python 2.7, the keys will be echoed to the screen, and you will also hear the beeps (meaning that the hook was seeing the keys, but was unable to actually block them -- its return value was being ignored). Also in Python 2.7, after the quit message is sent to the hook thread, GetMessageW (in user32.dll) causes a WindowsError exception. This does not happen on Python 2.6. Perhaps it may be related to this entry in the Python 2.7 What's new: The underlying libffi library has been updated to version 3.0.9, containing various fixes for different platforms. (Updated by Matthias Klose; issue 8142.) -- assignee: theller components: ctypes files: test_callbackRetval.py messages: 107447 nosy: mdcurran, theller priority: normal severity: normal status: open title: WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7 type: crash versions: Python 2.7 Added file: http://bugs.python.org/file17604/test_callbackRetval.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
Changes by Michael Curran m...@nvaccess.org: Added file: http://bugs.python.org/file17605/test_keyHook.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
Michael Curran m...@nvaccess.org added the comment: I should also note that this has been tested on Windows 7 and XP (32 bit). I have also seen cases where Python has crashed completely, rather than just causing a WindowsError, in these circomstances. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
Michael Curran m...@nvaccess.org added the comment: The issue does not occure with Python 2.7 beta 1, but does occure in Python 2.7 beta 2. So, with this in mind, its probably more likely that it may have been caused by the following change: - On Windows, ctypes does no longer check the stack before and after calling a foreign function. This allows to use the unmodified libffi library. I had previously thought it could have been the libffi upgrade, but this seems to have happened in Beta 1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
