[issue38597] C Extension import limit
New submission from Kevin Schlossser : System Windows 7 x64 SP2 Ram 16GB 6 Core AMD @ 3.2ghz CPython 3.7.2 C Extension (pyd) import cap. There seems to be a cap on the number of extensions that a package is able to contain. I am able to import 123 extension modules that my package has but when i go to import number 124 i get the following traceback ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. these extension modules are part of my package, importing an extension module from another package does not change this behavior. it is only when I import the 124th extension that is in my package does it occur. When I change the order of the imports the error does not follow the import. I end up getting the same error when the 124th extension gets loaded doesn't matter what extension it is. I have tried to see if maybe it was a module limit and I spread the imports across multiple files and it still fails when the 124th gets loaded. I also tried imp.load_dynamic and importlib.import_module and the same error occurs. If there is a way to work around this limitation it would be very helpful. -- components: Extension Modules messages: 355425 nosy: Kevin Schlossser priority: normal severity: normal status: open title: C Extension import limit type: resource usage versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39188] recent change when passing a Union to a function
New submission from Kevin Schlossser : OK so There was a change made to fix issue 26628. Something was forgotten about.. On Windows there is the VARIANT Union which gets used all over the Windows API. This change is going to really break a lot of peoples code and there are no code examples of what needs to be done to fix the now broken ctypes, what needs to be done instead of passing a Union? what new structure has been made that Windows is going to se as a Union? That is a huge change to make with no kind of notice that it was going to be done. Now I know it is publicly visible on your issue tracker, but come on now the issue was made 4 years ago and then all of a sudden out of no where boom broken software.. Now If that issue was a major issue and it was causing all kinds of grief I would think that it A. would have been fixed sooner... and B. there would have been more then a handful of people where the original "bug" caused a problem. I am wondering if maybe this bug is a NIX issue. there are simply way to many programs out that are running on Windows and Unions are being passed all the time in functions and no problems are occurring. If there were problems with it in Windows you would have 1000's of reports of crashing from this problem. A change like that should be posted on the Python website before it gets made so that all possible repercussions can be looked at. -- components: ctypes messages: 359187 nosy: Kevin Schlossser priority: normal severity: normal status: open title: recent change when passing a Union to a function type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38597] C Extension import limit
Kevin Schlossser added the comment: Thank you msg356892 for spear heading this for me. I family things to attend to so I apologize for opening this bug report and then walking away.. As far as recreating this issue. It simple to do. you can either use cython or you can put together a quick script that will make say 150 extensions. put one line of code in it and compile it.. The results always end up being the same 123 extensions can be loaded on the 124th a TB happens.. It does not matter where the files are inside the package. it is always the 124th one that gets loaded for any one package. importing a pyd from another package does not change the number. The extensions have to be a direct descendant of one single package. -- ___ Python tracker <https://bugs.python.org/issue38597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39217] GC of a ctypes object causes application crash
New submission from Kevin Schlossser :
I guess this is a question as much as it is a bug report. I know that all kinds
of strange behavior can happen when using ctypes improperly. This is what is
taking place. I can provide code if needed. but lets work off of my description
of what is taking place first.
I am querying DeviceIoControl which is apart of the Windows API..
I have a function that has ctypes objects passed to it.. it does whatever it is
that is needed to call DeviceIoControl. I have narrow it down to a single
object and I ran the visual studio debugger and it traced the problem back to
the garbage collector.
So this is the basic layout..
```python
def IOControl(io_ctrl, inBuffer, outBuffer, outBufferSize=None):
if outBuffer is None:
outBufferSize = INT(0)
else:
pOutBuffer = ctypes.byref(outBuffer)
if outBufferSize is None:
outBufferSize = INT(ctypes.sizeof(outBuffer))
else:
outBufferSize = INT(outBufferSize)
if inBuffer is None:
inBufferSize = INT(0)
else:
pInBuffer = ctypes.byref(inBuffer)
inBufferSize = INT(ctypes.sizeof(inBuffer))
DeviceIOControl(
io_ctrl,
inBuffer,
ctypes.byref(inBufferSize),
outBuffer,
ctypes.byref(outBufferSize)
)
class SomeStructure(ctypes.Structure):
_fields_ = [
('SomeField1', ULONG),
('SomeField2, LONG * 100,
]
out_buffer = SomeStructure()
buf_size = ctypes.sizeof(out_buffer)
IOControl(
'some io control code',
None,
None,
out_buffer ,
buf_size
]
```
The code above will crash Python and the debug leads back to an error in the GC.
I do not know what the internals of ctypes are or how they function. when using
ctypes.byref() to create a pointer I would imagine that the original instance
is held somewhere inside of the pointer. But when it gets passed off to the
Windows function where it does or what it does is unknown to me. The process if
doing this is more complex then what is above It is for example purposes..
There is another in the Windows API that will wait for data to be had from the
first function call.
The funny thing is the first time it goes though IOControl without incident.
its repeated attempts that cause the appcrash.
If someone has a reason as to why this is taking place I am ready to
learn!!!... I find it odd behavior that once i mode the code from that function
into the same namespace where that function was originally called form
everything works fine and no application crashes happen
The debugger pointed to data that was being passed to a GC macro or function
that did not have the information correct. It was pretty car into the GC code
before the application crash happens.
I am also able to provide the results of running the debugger
any help/information would be greatly appreciated.
--
components: ctypes
messages: 359318
nosy: Kevin Schlossser
priority: normal
severity: normal
status: open
title: GC of a ctypes object causes application crash
type: crash
versions: Python 2.7, Python 3.7
___
Python tracker
<https://bugs.python.org/issue39217>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
