[Mono-dev] Marshal.GetFunctionPointerForDelegate and non-mono threads
alan.mcgovern at gmail.com
Tue Jan 29 13:00:41 UTC 2013
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.
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.
> 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
>> 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
> Yuriy Solodkyy
> (y.solodkyy at gmail.com)
More information about the Mono-devel-list