Hi,

  I tried the example code which creates appdomains from C code and it
really does crash
because some things are only set up in the runtime when mono_jit_exec
() is called. So
your workaround of calling CreateDomain () from managed code seems to
be the way to
go, at least for now. I tried it and it seems to work on linux, I will
try to look into the
windows problems shortly.

                     Zoltan

On 1/11/06, Jim Purbrick <[EMAIL PROTECTED]> wrote:
> 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 <[EMAIL PROTECTED]> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Reply via email to