[Mono-list] Mono embedding - null pointer access violation on ves_icall_System_Reflection_Assembly_GetExecutingAssembly

[Jonathan Chambers]

I saw the same issue in an embedding case I am doing. I worked around it
ATM by not calling some C# code, but when I take time to debug/fix I'll
post it here.

Thanks,
Jonathan


On Thu, Apr 25, 2013 at 6:30 PM, <Jean-Michel.Perraud at csiro.au> wrote:

>  Hi Rodrigo,****
>
> ** **
>
> I get the same behaviour whether I attach before or after loading the mono
> runtime, and 32 or 64 bit process.****
>
> I cannot figure out what I changed so much to end up in this pickle. But I
> could certainly do with a code review from someone more seasoned with mono
> embedding. My MS.NET embedding side is getting very usable, but visibly
> the Mono side has bugs I am not on top of.****
>
> Happy to provide further information as needed.****
>
> ** **
>
> Regards****
>
> ** **
>
> *From:* Rodrigo Kumpera [mailto:kumpera at gmail.com]
> *Sent:* Tuesday, 23 April 2013 12:50 AM
> *To:* Perraud, Jean-Michel (CLW, Black Mountain)
> *Cc:* Mono List
> *Subject:* Re: [Mono-list] Mono embedding - null pointer access violation
> on ves_icall_System_Reflection_Assembly_GetExecutingAssembly****
>
> ** **
>
> Did you attach the thread before calling into the mono runtime?****
>
> ** **
>
> On Fri, Apr 12, 2013 at 8:00 PM, <Jean-Michel.Perraud at csiro.au> wrote:****
>
> 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  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list****
>
> ** **
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130426/9bc038d7/attachment-0001.html>