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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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
=== message truncated ===
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
