No reason not to fix this bug though :) I'd suggest that readline should check for dllhandle being 0 and have some sort of graceful fallback. Long term we might find having a fake dllhandle might be useful - that way we could work better with ctypes code doing low level stuff.
From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P Sent: Thursday, February 11, 2010 10:46 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6.1 RC1, ctypes, and c_int.value Dino, The readline module is patching the PyOS_ReadLineFunctionPointer variable in the DLL that implements the sys module (in CPython's case, this is the Python26.dll). Since IronPython doesn't support intercepting line reads in this way (or at all, apparently), this isn't going to work on IronPython in any event. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, February 11, 2010 10:40 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6.1 RC1, ctypes, and c_int.value I've created http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26185 but I already have a fix for this. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, February 11, 2010 10:14 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6.1 RC1, ctypes, and c_int.value 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: users-boun...@lists.ironpython.com [mailto:users-boun...@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.lepi...@intel.com<mailto:stephen.p.lepi...@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@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
