[Ironpython-users] AccessViolationException on Python.CreateEngine() call
Dino Viehland
dinov at microsoft.com
Tue Aug 9 05:45:32 CEST 2011
The AV exception here indicates that something is going wrong in native code - it sounds
like it could be a CLR bug or a crash in some other component. Does this all repro with
just ipy.exe (so in 32-bit mode)?
The best way to figure out what's going on is to use the native debuggers. You can
download those here: http://www.windbg.org/ (Note if you don't want to run the
installer on the user's machine it is possible to xcopy them from one machine to
another).
Given that it seems to repro w/ just running ipy64.exe you should be able to just do
something like:
"C:\Program Files (x86)\Debugging Tools for Windows\windbg.exe" "C:\Program Files\IronPython 2.6\ipy64.exe"
Once it's started you should just type "g" and enter in the command line (or use the menus to go :))
and it should stop when the crash is hit. From there into the command line you can type:
.symfix
.reload
~*kb30
That will set the symbol path to Microsoft's public symbol servers, reload symbols, and then
dump the stack trace of all the threads. It might also be useful to know the version of the CLR
if it's crashing in mscorwks, you can do:
lm v mmscorwks
To get that. And finally if it is a CLR bug someone might want a crash dump which you could get
with:
.dump /mfh somelocation.dmp
but just hold onto that for now - it's just in case and I don't have an easy place to send it to.
> -----Original Message-----
> From: Jeff Hardy [mailto:jdhardy at gmail.com]
> Sent: Monday, August 08, 2011 12:35 PM
> To: Igor Brejc
> Cc: ironpython-users at python.org; Dino Viehland
> Subject: Re: [Ironpython-users] AccessViolationException on
> Python.CreateEngine() call
>
> Two quick answers:
> 1. It's not critical, unless you need access COM objects (like Word/Excel
> automation or something).
> 2. The exact same code is in 2.7, and I think it's still active.
> 3. I can't understand why it would break like that when examining those
> assemblies.
>
> Dino? Thoughts?
>
> - Jeff
>
> On Mon, Aug 8, 2011 at 12:27 PM, Igor Brejc <igor.brejc at gmail.com> wrote:
> > 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:
> >
> > Is there any reason why both assemblies are examined twice?
> > How critical is this method for running IP? In other words if I
> > comment it out, would IP be able to work normally?
> > 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_AssemblyL
> >> >>> > oaded(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.LoadLanguageC
> >> >>> > ontext(ScriptDomainManager domainManager, Boolean&
> >> >>> > alreadyLoaded) at
> >> >>> >
> >> >>> > Microsoft.Scripting.Runtime.DlrConfiguration.LoadLanguageContex
> >> >>> > t(ScriptDomainManager manager, LanguageConfiguration config) at
> >> >>> >
> >> >>> > Microsoft.Scripting.Runtime.DlrConfiguration.TryLoadLanguage(Sc
> >> >>> > riptDomainManager manager, AssemblyQualifiedTypeName
> >> >>> > providerName, LanguageContext&
> >> >>> > language)
> >> >>> > at
> >> >>> >
> >> >>> >
> Microsoft.Scripting.Runtime.ScriptDomainManager.GetLanguageByTy
> >> >>> > peName(String
> >> >>> > providerAssemblyQualifiedTypeName)
> >> >>> > at
> >> >>> >
> Microsoft.Scripting.Hosting.ScriptRuntime.GetEngineByTypeName(S
> >> >>> > tring
> >> >>> > 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