[Mono-dev] Creating AppDomains From Embedded Mono

[Jim Purbrick]

Fixed!

It looks as though the problem was with the
environment as I suspected. Once I made the assemblies
available to mono either by copying them to the
working directory or by using mono_set_dirs() the
CreateDomain crash went away. I'm not sure why it
didn't work when I had MONO_PATH and MONO_CFG_DIR set,
but anyway.

The second crash which occured the first time I tried
to use mono_assembly_open() or
mono_domain_assembly_open() to load an assembly in to
the new domain seems to have been caused by calling
CreateDomain directly and then extracting the
MonoDomain* from the MonoAppDomain: switching back to
my orignal mechanism (which executed an assembly in
the new domain which called mono_domain_get() via an
icall to get the new MonoDomain*) seems to fix things.

In the future an easy way to create domains from C
and/or an easy way to get the MonoDomain* from a
MonoAppDomain would be nice as using icalls and
calling back and forth between managed and unmanaged
code is a faff, but it's not essential.

Robert, Paolo and Zoltan, thanks for all your help!

Cheers,

Jim.

--- Zoltan Varga <vargaz at gmail.com> wrote:

>                                                   
> Hi,
> 
>   I tried reproducing the crash in CreateDomain, but
> it seems to work
> fine for me even on
> windows (using mono SVN). I will try 1.1.13 later.
> As for this new
> crash, I think you should
> call mono_domain_assembly_open () instead of
> mono_assembly_open ().
> 
>                                                     
>           Zoltan
> 
> On 1/12/06, Jim Purbrick <jimpurbrick at yahoo.co.uk>
> wrote:
> > Hi Robert,
> >
> > Setting MONO_CFG_DIR to C:\Apps\Mono-1.1.13\etc
> and
> > MONO_PATH to C:\Apps\Mono-1.1.13\lib didn't seem
> to
> > help.
> >
> > Calling
> mono_set_dirs("C:\\Apps\\Mono-1.1.13\\lib",
> > "C:\\Apps\\Mono-1.1.13\\etc") before calling
> > mono_jit_init("root domain") helped a bit in that
> I
> > could get rid of the System, PEAPI and
> > Mono.CompilerServices.SymbolWriter DLLs that I'd
> had
> > to copy to the debugsim.exe directory, but I still
> get
> > the crash on the call to
> > mono_assembly_open("Script.dll",...).
> >
> > Thanks for all your help,
> >
> > Cheers,
> >
> > Jim.
> >
> > --- Robert Jordan <robertj at gmx.net> wrote:
> >
> > > Hi Jim,
> > >
> > > I had a regression (it was actually my
> mistatake)
> > > with 1.1.13
> > > under Windows with my own mono embedding apps: I
> > > forgot
> > > to set MONO_CFG_DIR to point to mono's etc
> > > directory.
> > > This seems to prevent System.dll from beeing
> > > correctly
> > > loaded.
> > >
> > > You should either set both MONO_PATH and
> > > MONO_CFG_DIR
> > > or use
> > >
> > > mono_set_dirs (libdir, etcdir)
> > >
> > > before calling mono_jit_init ().
> > >
> > > HTH
> > > Robert
> > >
> > >
> > > > 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
> 
=== message truncated ===



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com