[IronPython] IronPython 2.6.1 RC1, ctypes, and c_int.value

Dino Viehland dinov at microsoft.com
Thu Feb 11 19:14:15 CET 2010

Actually this looks like a bug in IronPython.  ctypes.addressof(msvcrt.system) is returning the wrong value - in CPython it's returning the address which points to the function.  In IronPython it's returning the address of the function it's self.

Hopefully the real code is doing something more useful than this though because this seems to only be patching the ctypes pointer to the function, not any other pointers to the function.  So every call to system() will still go directly to the msvcrt impl.  I would assume this code really wanted to patch the exported address over in msvcrt.dll so all callers would be intercepted.   This doesn't even patch it if someone gets a 2nd copy of msvcrt via ctypes:

On my machine ctypes.addressof(msvcrt.system) is 12ff940 and msvcrt.system is "<_FuncPtr object at 0x012FF918>".  Then I do:

msvcrt2 = ctypes.cdll.LoadLibrary("msvcrt")

I get a new _FuncPtr object:

>>> msvcrt2.system
<_FuncPtr object at 0x012FF990>
>>> hex(ctypes.addressof(msvcrt2.system))

And now a different address would be patched.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Thursday, February 11, 2010 7:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.6.1 RC1, ctypes, and c_int.value

Wow, that's awful.

I imagine that you would need to use VirtualProtect to make that page writeable in order for this to work. I can't see how modifying IronPython's ctypes to make this possible would be a good idea -- the vast majority of uses for ctypes don't involve writing into arbitrary DLL code pages, and it's an extremely useful protection against stray writes.
On Thu, Feb 11, 2010 at 7:39 AM, Lepisto, Stephen P <stephen.p.lepisto at intel.com<mailto:stephen.p.lepisto at intel.com>> wrote:
Thank you for your efforts with IronPython 2.6.1.  I am looking forward to the final product.

I was testing 2.6.1 RC1 to see if an issue I was having with v2.6.0 was fixed and I ran into an interesting problem with pyReadLine (v1.13), which I had installed under CPython v2.6.4.  A python-based program I am testing requires the readline module but I am getting an odd  error when readline is loaded.  The error is "SystemError: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

I created a simple test case that shows the problem in action.  This test case runs fine under CPython v2.6.4 but fails under IronPython v2.6.1 RC1.  Please ignore the fact that it is really weird-looking code and not something that would normally be used.  The test case demonstrates the problem in as few lines as possible while exercising the same steps that readline uses (see the install_readline() function in readline's Console.py).

import ctypes
msvcrt = ctypes.cdll.LoadLibrary("msvcrt")
systemfn = ctypes.c_int.from_address(ctypes.addressof(msvcrt.system))
systemfn.value = ctypes.c_int.from_address(ctypes.addressof(msvcrt.system)).value

The last line triggers the error: "SystemError: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Apparently readline overwrites a function pointer ("PyOS_ReadlineFunctionPointer") inside the DLL that implements the sys module so that the line input functionality passes through the python readline module.  Since readline uses the sys.dllhandle to get access to the DLL and in IronPython v2.6.1 RC1 the sys.dllhandle is 0, I'm thinking the pyReadline package won't work on IronPython even if the above error is fixed.

Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100211/208cf0f9/attachment.html>

More information about the Ironpython-users mailing list