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

Jean-Michel.Perraud at csiro.au Jean-Michel.Perraud at csiro.au
Sun Apr 28 00:08:31 UTC 2013


Thanks Jonathan,

Happy to help if I can, providing information or otherwise. I cannot work around this one as it quickly bombs out with many essential function calls.
One thing I'll look at is whether having an entry point in the first loaded assembly is really still required, as stressed by Miguel in http://www.mono-project.com/Embedding_Mono. It seemed I could do away with it, but maybe this is still the case. Just a hunch, probably a red herring.

Regards

________________________________
From: Jonathan Chambers [joncham at gmail.com]
Sent: Saturday, April 27, 2013 4:29 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: Rodrigo Kumpera; mono-list at lists.ximian.com
Subject: Re: [Mono-list] Mono embedding - null pointer access violation on ves_icall_System_Reflection_Assembly_GetExecutingAssembly

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<mailto: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<http://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<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<mailto: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<mailto:Mono-list at lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-list


_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com<mailto: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/20130428/b26d8b50/attachment.html>


More information about the Mono-list mailing list