[Mono-dev] Creating AppDomains From Embedded Mono

[Jim Purbrick]

Hi Robert/Lupus/Everyone,

I've tried Robert's approach (which cleans my code up,
but is vulnerable to changes in _MonoAppDomain as
Paolo said), but I still get the same crash when
making the mono_runtime_invoke() call to
AppDomain.CreateDomain().

At this point I'm struggling with the limited
debugging I can do in VS 2003 when the code calls in
to glib or the mono. The error I get is Unhandled
exception at 0x10059acc in debugsim.exe: 0xC0000005:
Access violation reading location 0x00000007. And the
call stack is:

 	mono.dll!10059acc() 	
 	libglib-2.0-0.dll!0032bb3e() 	
 	mono.dll!10059bad() 	
 	libglib-2.0-0.dll!0032baf9() 	
 	mono.dll!10059736() 	
 	mono.dll!1002b3ba() 	
 	mono.dll!1002b7a0() 	
 	mono.dll!10067527() 	
	debugsim.exe!createDomain(const char *
name=0x0302edf8)  Line 31 + 0x11	C++

Which doesn't tell me a lot. I wonder whether the
problem is something to do with my new Windows
configuration as the code worked fine with mono
1.1.9.2 in my old Windows installation, but now I get
this problem with mono 1.1.9.2, 1.1.12.1 and 1.1.13.
Could some differences in the environment be causing
the problem? The value of MONO_PATH or some other
environment variable? This is just wild speculation
really. Is there anything else I can do to diagnose
the problem?

At the moment I'm thinking the best thing to do might
be to #define the code to use a single AppDomain on
Windows and just do the secondary AppDomain creation
and unloading on Linux, which is our production
environment anyway. I'm loathe to make the 2 versions
behave differently, but it would allow me to make some
forward progress while trying to sort this problem out
as a background task.

Thanks for all your help on this.

Cheers,

Jim.

--- Robert Jordan <robertj at gmx.net> wrote:

> Hi Jim,
> 
> > Hi Robert/Everyone,
> > 
> > 
> >>You can and *should* invoke the managed
> >>AppDomain methods to load and unload domains. 
> >>You don't need an intermediate managed assembly 
> >>to do that (untested):
> >>
> >>MonoAppDomain*
> >>createDomain (char *name) ....
> >>
> >>void
> >>unloadDomain (MonoAppDomain *domain) ...
> > 
> > 
> > That gets me a MonoAppDomain*, which I can
> presumably
> > use to call AppDomain.Load(Byte[]) to load a
> script's
> > assembly, which will be unloaded (along with JIT
> > output etc.) when I call unloadDomain?
> 
> MonoAppDomain is the unmanaged representation of
> System.AppDomain.
> You can call every System.AppDomain method using
> mono_runtime_invoke,
> like in my sample above.
> 
> > How do I turn the MonoAppDomain in to a MonoDomain
> > required by mono_object_new, mono_string_new etc.?
> 
> Indeed, there is no accessor defined for it, but you
> can
> define this struct somewhere after you include
> appdomain.h:
> 
> struct _MonoAppDomain {
>          MonoObject obj;
>          MonoObject *identity;
>          MonoDomain *data;
> };
> 
> > That is what my intermediate managed assemblies
> were
> > doing: executing an assembly in the new domain
> which
> > would call mono_domain_get() to get me a
> MonoDomain*
> > for the new MonoAppDomain.
>  >
> > Do I even need a MonoDomain* for the new
> > MonoAppDomain? At the moment I try to allocate any
> > objects used by a script in the AppDomain that I
> > loaded the script's assembly in to, but I suppose
> I
> > could allocate the other objects in the root
> domain.
> > Would there be any problems doing this? My concern
> > would be that the root domain would end up loading
> the
> > script's assembly which I then couldn't unload.
> 
> You have to use the proper MonoDomain.
> 
> Robert


		
___________________________________________________________ 
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com