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

[Sebastian Good]

Thanks. We are indeed keeping a reference around to the delegate to ensure it's not being collected. We use two such delegates, and the only one we see problems with is the one that's launched from these other worker threads. It's possible that there's something about these threads that is not friendly, not just the fact that mono didn't create them. 

On Jan 29, 2013, at 7:00 AM, Alan <alan.mcgovern at gmail.com> wrote:

> A simple way to diagnose if you're delegates have been GC'ed is to
> export MONO_DEBUG=keep-delegates. This instructs the GC to not collect
> delegates and instead rewrite them so that if they're invoked after
> they would normally have been GC'ed you get a nice diagnostic error
> message and then the runtime aborts. This is much easier to debug than
> a random crasher.
> 
> Alan
> 
> On 29 January 2013 07:49, Yuriy Solodkyy <y.solodkyy at gmail.com> wrote:
>> Do you keep a reference to your delegate while using the pointer? I suspect
>> GC just collect your delegate and function pointer becomes invalid.
>> 
>> -yuriy
>> 
>> 
>> On Tuesday, January 29, 2013, wrote:
>>> 
>>> 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
>>>>> 
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 
>> 
>> 
>> --
>> Yuriy Solodkyy
>> (y.solodkyy at gmail.com)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130129/de1655dc/attachment-0001.html>