[Ironpython-users] AccessViolationException on Python.CreateEngine() call
Igor Brejc
igor.brejc at gmail.com
Mon Aug 8 21:27:14 CEST 2011
Well in the end I built it from the ZIP package :).
Anyway, here are some results. IP always breaks down when
examining System.Runtime.Hosting.ActivationArguments type, on the
if (type.IsImport && type.IsInterface)
line. This is the only type the method breaks down on.
PublishComTypes examines the following assemblies:
2011-08-08 20:18:48,971 DEBUG [1]
Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
(interopassembly='mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089')
2011-08-08 20:18:50,490 DEBUG [1]
Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
(interopassembly='System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089')
2011-08-08 20:18:51,451 DEBUG [1]
Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
(interopassembly='mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089')
2011-08-08 20:18:52,695 DEBUG [1]
Microsoft.Scripting.Actions.TopNamespaceTracker - PublishComTypes
(interopassembly='System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089')
Questions:
1. Is there any reason why both assemblies are examined twice?
2. How critical is this method for running IP? In other words if I
comment it out, would IP be able to work normally?
3. Is there an improved version of this code in 2.7? The code comments
say "Since scanning all loaded assemblies can be expensive, in the future,
we might consider a more explicit user binder to trigger scanning of COM
types."
One other strange thing: _sometimes_ (looks like randomly), the method
throws AccessViolationException right at the start,
when AssemblyTypeNames.LoadTypesFromAssembly() is called on the mscorlib
assembly. I haven't added any logging in that method, so I cannot say where
exactly this happens. I can extend the logging if necessary.
Pasting the method code (without my logging code):
public static void PublishComTypes(Assembly interopAssembly)
{
#if !SILVERLIGHT
lock (_comTypeCache)
{ // We lock over the entire operation so that we can publish a
consistent view
foreach (Type type in
AssemblyTypeNames.LoadTypesFromAssembly(interopAssembly, false))
{
if (type.IsImport && type.IsInterface)
{
Type existing;
if (_comTypeCache.TryGetValue(type.GUID, out
existing))
{
if
(!existing.IsDefined(typeof(CoClassAttribute), false))
{
// prefer the type w/ CoClassAttribute
on it. Example:
// MS.Office.Interop.Excel.Worksheet
// vs
// MS.Office.Interop.Excel._Worksheet
// Worksheet defines all the interfaces
that the type supports and has CoClassAttribute.
// _Worksheet is just the interface for
the worksheet.
//
// They both have the same GUID though.
_comTypeCache[type.GUID] = type;
}
} else
{
_comTypeCache[type.GUID] = type;
}
}
}
}
#endif
}
On Mon, Aug 8, 2011 at 8:35 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> 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
> >>> >
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20110808/7b6e1805/attachment.html>
More information about the Ironpython-users
mailing list