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

[sebastian at palladiumconsulting.com]

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
threads.

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
>>