Hi,
I am trying to flush out bugs in an application with Mono (3.0.6) embedded.
Improving on the Linux front, an issue on Windows is now baffling me. The issue
seems deep in JIT exec code but has got to be because of my code.
I tried to condense the diagnosis with the (visual studio) native stack trace
(I could not get the managed part from MonoDevelop yet). I'd highly appreciate
the informed guess of a guru to suggest where to look to fix it.
Regards.
The high level call (in the R language) is like:
callStaticMethod( "SomeNamespace.AClassName", "TheStaticMethod",
"SomeString", "AnotherString" )
The main C code for preparing the CLR method call
MonoMethod * methodCallStaticMethod = rclr_mono_get_method(
spTypeClrFacade, "CallStaticMethodMono", 3);
void** static_mparams = (void**)malloc(3*sizeof(void*));
MonoArray* methParams = create_array_object(params, paramCount);
static_mparams[0] = create_mono_string(ns_qualified_typename);
static_mparams[1] = create_mono_string(methodName);
static_mparams[2] = methParams;
result = mono_runtime_invoke (methodCallStaticMethod, NULL,
static_mparams, &exception);
// calling the C# method:
// public static object CallStaticMethodMono(string typename, string
methodName, object[] arguments)
further in the stack strace, in:
icall.c : ves_icall_System_Reflection_Assembly_GetExecutingAssembly
(void)
the following line returns dest as a NULL pointer, which looks like a very
unexpected condition hence the crash.
mono_stack_walk_no_il (get_executing, &dest);
It seems that the root cause is in the function:
mono_walk_stack_full:
while (MONO_CONTEXT_GET_SP (&ctx) <
jit_tls->end_of_stack)
which is already false at the first iteration, hence 'dest' remains NULL.
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
