[Mono-dev] Marshal.GetFunctionPointerForDelegate and non-mono threads

sebastian at palladiumconsulting.com sebastian at palladiumconsulting.com
Tue Jan 29 03:00:28 UTC 2013

We are not using the debugger.

We're not sure how the library in question creates its threads. We
don't have access to its source code and it's proprietary. Putting
together a full repro would be hard.

The callback is a simple function which picks up a logged string and
sends it to NLog by way of an Rx Subject. That's a lot of moving
parts, but they all work fine when the callback comes from one of our

Am I correct in assuming that the GetFunctionPointerForDelegate should
automatically register the thread it's called on with mono? I have
enough facts at hand to call the registration function manually if
need be, but it would be awkward indeed.

On Jan 28, 2013, at 6:34 PM, Alan <alan.mcgovern at gmail.com> wrote:

> Do you see these issues when running with the soft debugger attached?
> If so, that was a bug which was fixed a few days ago. If you're seeing
> the issue without the debugger, a small testcase would be great for
> figuring this out.
> Alan
> On 28 January 2013 18:42, sebastian <sebastian at palladiumconsulting.com> wrote:
>> We run a program under mono which uses a 3rd party C++ library. Mono is
>> responsible for running the application, that is, we are not using the
>> mono_embed API, but rather just PInvoke to talk to the C++ library.
>> This library has some callbacks which we subscribe to using
>> Marhsal.GetFunctionPointerForDelegate. However we get exotic concurrency
>> problems (seg faults, inexplicable stacktraces) when we use it. We only get
>> these errors when the callback is made from a thread which was not started
>> by us.
>> I know that when embedding mono, i.e. with C++ in the driver's seat, threads
>> must be registered with mono using mono_thread_attach. However that would be
>> a funny thing for us to do, since we're not launching mono ourselves and
>> would have to do some exploration to find all the right pointers.
>> Does the code in GetFunctionPointerForDelegate emit a managed wrapper that
>> takes care of this detail? Once we are called back on this foreign thread,
>> there's no telling what or how much .NET code will run on it, and it
>> presumably needs to be properly registered with the garbage collector. I
>> looked at the code in mono_marshal_get_managed_wrapper and didn't see
>> anything obviously related to threading, but I imagine it'd be taken care of
>> at a lower level in any case.
>> We could easily be convinced the bugs we saw were GC or threading related,
>> as they could only be explained by corruption of things that shouldn't be
>> corruptible, like reflection and array bounds.
>> Or is there additional code or attributes we should be using to ensure
>> correct operation?
>> Thanks,
>> Sebastian
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list