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")
msvcrt2.system
I get a new _FuncPtr object:
>>> msvcrt2.system
<_FuncPtr object at 0x012FF990>
>>> hex(ctypes.addressof(msvcrt2.system))
'0x12ff9b8'
And now a different address would be patched.
From: [email protected]
[mailto:[email protected]] 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
