Title: GC of a ctypes object causes application crash
Type: crash Stage: resolved
Components: ctypes Versions: Python 3.9
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Kevin Schlossser, iritkatriel, terry.reedy
Priority: normal Keywords:

Created on 2020-01-05 01:59 by Kevin Schlossser, last changed 2021-06-15 11:31 by iritkatriel. This issue is now closed.

Messages (3)
msg359318 - (view) Author: Kevin Schlossser (Kevin Schlossser) Date: 2020-01-05 01:59
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..


def IOControl(io_ctrl, inBuffer, outBuffer, outBufferSize=None):

    if outBuffer is None:
        outBufferSize = INT(0) 

        pOutBuffer = ctypes.byref(outBuffer)

        if outBufferSize is None:
            outBufferSize = INT(ctypes.sizeof(outBuffer))
            outBufferSize = INT(outBufferSize)

    if inBuffer is None:
        inBufferSize = INT(0) 
        pInBuffer = ctypes.byref(inBuffer)
        inBufferSize = INT(ctypes.sizeof(inBuffer))


    class SomeStructure(ctypes.Structure):

        _fields_ = [
            ('SomeField1', ULONG),
            ('SomeField2, LONG * 100,

out_buffer = SomeStructure()
buf_size = ctypes.sizeof(out_buffer)

    'some io control code', 
    out_buffer , 

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.
msg359768 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-01-10 23:10
"Is this a bug" questions are often better asked on python-list.  (I don't know.)  If so, the bug needed to be tested on the current development version (3.9 now).  Likely, someone on python-list will try given reproducible code.

2.7 has reach EOL.
msg395869 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-15 11:31
As Terry suggested, it would be better to establish whether this is a python bug by asking on python-list, where more people are likely to see your question.

A complete script reproducing the crash is *always* better than a verbal description that we may or may not understand correctly.

Please reopen this or create a new issue if you are still seeing this issue on a recent (3.9+) version and you can provide a complete script that reproduces it.
Date User Action Args
2021-06-15 11:31:21iritkatrielsetstatus: open -> closed

nosy: + iritkatriel
messages: + msg395869

resolution: rejected
stage: resolved
2020-01-10 23:10:47terry.reedysetnosy: + terry.reedy

messages: + msg359768
versions: + Python 3.9, - Python 2.7, Python 3.7
2020-01-05 01:59:59Kevin Schlosssercreate