[Ironpython-users] AccessViolationException on Python.CreateEngine() call
Igor Brejc
igor.brejc at gmail.com
Tue Aug 9 08:35:29 CEST 2011
Hi Dino,
It fails both on ipy and ipy64.
Unfortunately I'm not sure executing such a debugging would really be an
option, I communicate with the user via email only and it would be too much
to ask of him to do these debugging steps himself (I already bothered him
enough with all the "try this" stuff :) ). I could ask him of course, but
it's up to him, I guess.
The thing is that I cannot say this same error happens on any other machine,
so until I can get some more statistics from multiple users having this same
problem, I guess I'll leave it as it is. The user says that he has a lot of
software installed, so it could be something unique in his configuration
that's causing the problem.
What I'm trying out right now is giving him an IP build with
the PublishComTypes method effectively commented out (just like it is for
the Silverlight build), since not having COM types exposed is not a big
issue for my use case. I'll let you know if this helps or not.
Thanks for your help,
Igor
On Tue, Aug 9, 2011 at 5:45 AM, Dino Viehland <dinov at microsoft.com> wrote:
> 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
> > >> >>> >
> > >> >>
> > >> >
> > >> >
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20110809/aba14d51/attachment.html>
More information about the Ironpython-users
mailing list