[Ironpython-users] AccessViolationException on Python.CreateEngine() call

Jeff Hardy jdhardy at gmail.com
Mon Aug 8 20:35:15 CEST 2011


IronPython_2_6 should be all you need. The rest is the start of 2.7
that later got moved to GitHub.

- Jeff

On Mon, Aug 8, 2011 at 10:50 AM, Igor Brejc <igor.brejc at gmail.com> wrote:
> Hi Jeff,
> One question: I'm looking at the codeplex SVN repository (since I assume
> this is where 2.6.2 code still resides). What exactly do I need to check out
> in order to be able to build it? IronPython_2_6 directory or the whole
> repository? There seems to be a lot of stuff in the IronPython_Main dir.
> Thanks,
> Igor
>
> On Mon, Aug 8, 2011 at 7:17 PM, Igor Brejc <igor.brejc at gmail.com> wrote:
>>
>> Hi Jeff,
>> Thanks for responding. I'll update the SO question if/when someone (I
>> guess it will probably have to be me) figures out what the problem is.
>> One update: we did some more debugging. The user installed IronPython
>> 2.6.2 msi (.NET 2.0) and ipy64.exe breaks down when run. I guess this
>> excludes any of my code or the fact that IP was used outside of GAC.
>> What's strange is that sometimes it's AccessViolationException and
>> sometimes NullReferenceException (but the failing method is the same).
>> So I guess I'll need to build a custom IP build with some log4net logging
>> of that method, since live debugging is not a realistic option here.
>> Thanks for your help,
>> Igor
>>
>> On Mon, Aug 8, 2011 at 6:12 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>>
>>> Hi Igor,
>>>
>>> The exception is occurring somewhere in IronPython's COM interop code,
>>> but I'm not exactly sure why - the code where the exception occurred
>>> pulls COM types out of interop assemblies. You'll have to (somehow)
>>> figure out what assembly is getting loaded in the AppDomain when the
>>> exception happens, which will probably require live debugging or a
>>> custom IronPython build.
>>>
>>> I'm not sure if it's a bug in IronPython, or if there's a squirrelly
>>> COM object on the user's machine that causes IronPython to break, but
>>> my guess is the latter.
>>>
>>> - Jeff
>>>
>>> P.S. I saw your SO question before this, but feel free to keep the
>>> discussion where ever you prefer.
>>>
>>> On Sat, Aug 6, 2011 at 11:12 PM, Igor Brejc <igor.brejc at gmail.com> wrote:
>>> > Hi,
>>> >
>>> > I'm developing a cartography application (http://maperitive.net) in C#
>>> > and I plan to use IronPython as a scripting extension of the
>>> > application. I've been successfully using IronPython for several
>>> > months and most users don't have any issues with it, but a small
>>> > percentage of users is having problems.
>>> >
>>> > With the help from one of them I managed to dig out the exception
>>> > stack trace. The exception occurs while calling the
>>> > Python.CreateEngine() method:
>>> >
>>> > System.Reflection.TargetInvocationException: Exception has been thrown
>>> > by the target of an invocation.
>>> > ---> System.Reflection.TargetInvocationException:
>>> > Failed to load language 'IronPython 2.6.2': Attempted to read or write
>>> > protected memory. This is often an indication that other memory is
>>> > corrupt.
>>> > ---> System.AccessViolationException: Attempted to read or write
>>> > protected memory. This is often an indication that other memory is
>>> > corrupt.
>>> > at
>>> > Microsoft.Scripting.Actions.TopNamespaceTracker.PublishComTypes(Assembly
>>> > interopAssembly)
>>> > at
>>> > IronPython.Runtime.Binding.PythonBinder.DomainManager_AssemblyLoaded(Object
>>> > sender, AssemblyLoadedEventArgs e)
>>> > at IronPython.Runtime.Binding.PythonBinder..ctor(PythonContext
>>> > pythonContext, CodeContext context)
>>> > at IronPython.Runtime.PythonContext..ctor(ScriptDomainManager manager,
>>> > IDictionary`2 options)
>>> > --- End of inner exception stack trace ---
>>> > at
>>> > Microsoft.Scripting.Runtime.LanguageConfiguration.LoadLanguageContext(ScriptDomainManager
>>> > domainManager, Boolean& alreadyLoaded)
>>> > at
>>> > Microsoft.Scripting.Runtime.DlrConfiguration.LoadLanguageContext(ScriptDomainManager
>>> > manager, LanguageConfiguration config)
>>> > at
>>> > Microsoft.Scripting.Runtime.DlrConfiguration.TryLoadLanguage(ScriptDomainManager
>>> > manager, AssemblyQualifiedTypeName providerName, LanguageContext&
>>> > language)
>>> > at
>>> > Microsoft.Scripting.Runtime.ScriptDomainManager.GetLanguageByTypeName(String
>>> > providerAssemblyQualifiedTypeName)
>>> > at Microsoft.Scripting.Hosting.ScriptRuntime.GetEngineByTypeName(String
>>> > assemblyQualifiedTypeName)
>>> > at IronPython.Hosting.Python.GetEngine(ScriptRuntime runtime)
>>> >
>>> > I couldn't find anything on Google that would be related to this. Some
>>> > info about the user's environment:
>>> >
>>> > - Win7 64bit
>>> > - Using .NET 2.0-3.5 (not 4.0)
>>> > - IronPython is not installed in GAC, the app uses assemblies locally
>>> > on the disk (v 2.6.2)
>>> > - The user runs the application as an ordinary user (not administrator)
>>> >
>>> > I use Win7 64bit myself, but I didn't have any such problems and I
>>> > cannot reproduce this problem on any of my machines (Win7, Ubuntu).
>>> >
>>> > Thanks for any help,
>>> > Igor Brejc
>>> > _______________________________________________
>>> > Ironpython-users mailing list
>>> > Ironpython-users at python.org
>>> > http://mail.python.org/mailman/listinfo/ironpython-users
>>> >
>>
>
>


More information about the Ironpython-users mailing list