[Mono-dev] Creating AppDomains From Embedded Mono
Jim Purbrick
jimpurbrick at yahoo.co.uk
Wed Jan 11 16:18:24 EST 2006
Hmmm, I may be on to something...
I just noticed a warning saying that System.dll, which
is referenced by another loaded assembly, couldn't be
found and that the Mono-INFO messages (output as I
have MONO_LOG_LEVEL set to debug as a Windows
environment variable) suggest that mono isn't looking
for assemblied in the MONO_PATH, which is set to
C:\Apps\Mono-1.1.13\lib. If I copy System.dll from
C:\Apps\Mono-1.1.13\lib\mono\1.0 to the same directory
as debugsim.exe then I no longer get the warning about
System.dll _AND_ the error message on the call to
AppDomain.CreateDomain() changes to Unhandled
exception at 0x7c964ed1 in debugsim.exe: 0xC0000008:
An invalid HANDLE was specified. With the following
stack trace:
ntdll.dll!7c964ed1()
ntdll.dll!7c964ed1()
ntdll.dll!7c9268ad()
ntdll.dll!7c91056d()
ntdll.dll!7c90e9c0()
ntdll.dll!7c91901b()
ntdll.dll!7c94243c()
msvcrt.dll!77c2c2de()
ntdll.dll!7c91056d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
ntdll.dll!7c90104b()
mono.dll!1005a60e()
mono.dll!10079c8a()
mono.dll!10078dc9()
mono.dll!1007a813()
mono.dll!1007a327()
mono.dll!1007a4e0()
mono.dll!1007a5e0()
debugsim.exe!load_class(_MonoDomain *
domain=0x03839ae8)
So, have I just set up MONO_PATH incorrectly so the
embedded mono VM can't find the assemblies it needs
when it makes the AppDomain.CreateDomain() and
mono_assembly_open() calls? That would fit my theory
that it's something to do with my new Windows set up
that is causing the problem. Currently my MONO_PATH is
set to C:\Apps\Mono-1.1.13\lib in the "User variables"
section of the environment. Does that sound right?
Should I see Mono-INFO messages about probing
directories on the MONO_PATH if everything is working
properly? I don't remember seeing warnings about
unfound assemblies or having to copy assemblies to the
debugsim.exe directory before.
Thanks again for all your help,
Cheers,
Jim.
--- Jim Purbrick <jimpurbrick at yahoo.co.uk> wrote:
> Thanks Zoltan,
>
> I've got it working on Linux too and it used to work
> on Windows until my hard drive died and I needed to
> reinstall. I can't think how my old and new Windows
> installations differ, so if you get it working I'll
> be
> interested to know how your Windows machine is set
> up
> and also how you're building mono on Windows. I
> build
> mono from source in cygwin using then build the
> mono.dll using:
>
> gcc -mno-cygwin -O -g -O2 -fno-strict-aliasing -g
> -Wall -Wunused -Wmissing-prototypes
> -Wmissing-declarations -Wstrict-prototypes
> -Wmissing-prototypes -Wnested-externs
> -Wpointer-arith
> -Wno-cast-qual -Wcast-align -Wwrite-strings -shared
> -o
> mono.dll main.o -Wl,--export-dynamic
> -Wl,--export-dynamic ./.libs/libmono.a
> -L/usr/local/lib -lgthread-2.0 -lgmodule-2.0
> -lglib-2.0 -lintl -liconv -lws2_32 -lpsapi -lole32
>
> I've looked in to building Mono in VS before, but at
> the time I looked in to it there were problems with
> stack walking, so not everything worked when you
> built
> Mono with VS and also you needed VS 2005 which was
> only in beta at the time and SL only built in VS
> 2003.
>
> Cheers,
>
> Jim.
>
> --- Zoltan Varga <vargaz at gmail.com> wrote:
>
> >
> > 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 <jimpurbrick at yahoo.co.uk>
> > 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 <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
>
=== message truncated ===
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
More information about the Mono-devel-list
mailing list