[issue47001] deadlock in ctypes?
Rocco Matano added the comment: I forgot to say thank you. I would like to make up for that: Thank you, Eryk. -- ___ Python tracker <https://bugs.python.org/issue47001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47001] deadlock in ctypes?
Rocco Matano added the comment: @Eryk I think you hit the nail on the head with your recommendation to avoid ctypes.c_wchar_p (i.e. wintypes.LPWSTR) as the parameter type when dealing resource type/name strings. Of course ctypes automatic conversion from a C character pointer to a Python string will cause problems when being confronted with a 16-bit ID that is NOT a valid pointer. Now that it is clear that the problem was in front of the monitor, I consider this case closed. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47001] deadlock in ctypes?
New submission from Rocco Matano :
When using ctypes under Windows, I have observed a baffling behavior which I am
not sure if it is the result of a bug in ctypes, or is simply due to false
expectations on my part.
Environment:
- Windows 10 Pro, 21H1, 19043.1586, x64
- Python versions 3.6 up to 3.10, x64
What I was trying to do was to enumerate all the icons in the resource section
of an executable file. The Windows-API for such a case is EnumResourceNamesW,
which requires the pointer to a callback function as an argument. I wanted to
hide the details of the corresponding code so that a user of that code does not
have to deal with ctypes directly and can supply a regular Python function for
the callback. So I added an extra level of indirection.
When I ran my code, I was surprised to observe that the program was stuck.
After several tries, I found a solution that differed from the original code
only in one small detail: Use different types when describing the C callback.
Below is a self contained sample that can be used to show the successful case
as well as to trigger the blocking. Unfortunately it is quit long.
import sys
import ctypes
from ctypes.wintypes import HMODULE, LPVOID, LPWSTR, BOOL
# context structure that is used to use regular python functions as callbacks
# where external C code expects C callbacks with a certain signature.
class CallbackContext(ctypes.Structure):
_fields_ = (
("callback", ctypes.py_object),
("context", ctypes.py_object),
)
CallbackContextPtr = ctypes.POINTER(CallbackContext)
# quote from
#
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nc-libloaderapi-enumresnameprocw
#
# BOOL Enumresnameprocw(
# [in, optional] HMODULE hModule,
# LPCWSTR lpType,
# LPWSTR lpName,
# [in] LONG_PTR lParam
# )
# Note that the arguments lpType and lpName are declared as pointers to strings.
if len(sys.argv) > 1 and sys.argv[1].lower() == "fail":
# Declaring them as pointers to strings in the ctypes prototype does NOT
work.
EnumResNameCallback_prototype = ctypes.WINFUNCTYPE(
BOOL,
HMODULE,
LPWSTR,
LPWSTR,
CallbackContextPtr
)
else:
# Declaring them as void pointers does work!
EnumResNameCallback_prototype = ctypes.WINFUNCTYPE(
BOOL,
HMODULE,
LPVOID,
LPVOID,
CallbackContextPtr
)
# this is the ctypes callback function that mimics the required C call signature
@EnumResNameCallback_prototype
def EnumResNameCallback(hmod, typ, name, ctxt):
cbc = ctxt.contents
return cbc.callback(hmod, typ, name, cbc.context)
kernel32 = ctypes.windll.kernel32
EnumResourceNames = kernel32.EnumResourceNamesW
EnumResourceNames.restype = BOOL
EnumResourceNames.argtypes = (
HMODULE,
LPWSTR,
EnumResNameCallback_prototype,
CallbackContextPtr
)
# Get a module handle for an executable that contains icons
GetModuleHandle = kernel32.GetModuleHandleW
GetModuleHandle.restype = HMODULE
GetModuleHandle.argtypes = (LPWSTR,)
hmod = GetModuleHandle(sys.executable)
if hmod == 0:
raise ctypes.WinError()
RT_GROUP_ICON = ctypes.cast(14, LPWSTR)
# this is the 'regular' callback function that does not have to care about
# the C call signature
def enum_callback(hmod, typ, name, unused_context):
print(hmod, typ, name)
return True
cbc = CallbackContext(enum_callback, None)
rcbc = ctypes.byref(cbc)
print("Trying to enumerate icons.")
print("In the case of failure, this WILL BLOCK indefinitely!")
EnumResourceNames(hmod, RT_GROUP_ICON, EnumResNameCallback, rcbc)
--
components: ctypes
messages: 415029
nosy: rocco.matano
priority: normal
severity: normal
status: open
title: deadlock in ctypes?
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue47001>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Rocco Matano added the comment: I just experienced the described problem using Python 3.6.0 (Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32), but i do not understand the current status of this issue: On the one hand it is marked as 'open', which seems to imply that is still not resolved. On the other hand the resolution was set to 'fixed' in May 2015. Should i open a new issue for Python 3.6? -- nosy: +rocco.matano versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25118] OSError in os.waitpid() on Windows [3.5.0 regression]
Rocco Matano added the comment: I know that using os.spawn and and os.waitpid this way is not the best option, but a 3rd party tool i am using (scons) is doing it that way. So no scons with Python 3.5.0. (I am also aware that scons does not yet support Python 3.x officially.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25118] OSError in os.waitpid
New submission from Rocco Matano:
On windows and python up to 3.4 using the combination of os.spawnX(os.P_NOWAIT,
...) and os.waitpid() worked as expected, but with python 3.5 this no longer
works. In fact os.waitpid() now raises an OSError when the child process
terminates.
Running this simple script demonstrates that:
import sys
import os
import time
print(sys.version)
file = r'c:\windows\system32\cmd.exe'
args = [file, '/C', 'ping', '1.1.1.1', '-n', '1', '>NUL']
env = os.environ
t0 = time.time()
ret = os.spawnve(os.P_NOWAIT, file, args, env)
pid, status = os.waitpid(ret, 0)
t1 = time.time()
print("process took %.1f seconds" % (t1 - t0))
I get the following outputs:
C:\Users\rmatano\test_py35>py -3.4 test_waitpid.py
3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)]
process took 3.6 seconds
C:\Users\rmatano\test_py35>py -3.5 test_waitpid.py
3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)]
Traceback (most recent call last):
File "twp.py", line 13, in
pid, status = os.waitpid(ret, 0)
OSError: [Errno 0] Error
I guess this is a bug rather than a intended change in behavior, isn't it?
--
components: Library (Lib)
messages: 250723
nosy: rocco.matano
priority: normal
severity: normal
status: open
title: OSError in os.waitpid
type: behavior
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25118>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
