[Mono-dev] Creating AppDomains From Embedded Mono
Robert Jordan
robertj at gmx.net
Thu Jan 12 01:30:29 EST 2006
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
>>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