[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

[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

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 7.0 -> 8.0 pull_requests: +24821 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/26204 ___ Python tracker

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Steve Dower added the comment: Even better, one that doesn't crash but safely returns a value that can be checked. (IIRC, we have a test that does this to ensure that structs smaller than 9 bytes are passed on the stack.) Half C/half Python is fine - the C bits would go into _ctypes_test.c

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Christian Heimes added the comment: It would help us if you or Michael could provide a minimal reproducer of the crash in form of a unit test and submit it as pull request. -- nosy: +christian.heimes versions: +Python 3.10 ___ Python tracker

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

David Heffernan added the comment: @Steve as a user of Python rather than a Python developer, I don't know what the process here. I understand the need for a test, and then a fix. And I would not be surprised if the act of fixing the issue led to a broadening of the test if the scope of the

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Steve Dower added the comment: My previous post still stands. This requires a test and then (hopefully) a fix in ctypes or (potentially) a fix upstream in libffi. -- ___ Python tracker

[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

[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

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Steve Dower added the comment: I would guess this is due to the updated libffi, and probably it's a case that is not sufficiently tested. Adding tests is the first step. It'll probably have to enumerate many parameter types (in case there's something weird here like misaligning the double

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

Change by Eryk Sun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___ ___

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

New submission from David Heffernan : Starting with Python 3.8 certain ctypes callbacks fail to restore the stack pointer. In the repo below, when the DLL is compiled with MSVC under default debug settings, running the Python script leads to a debug error dialog which says: Run-Time Check