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.solod...@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.mcgov...@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 <sebast...@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@lists.ximian.com >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > -- > Yuriy Solodkyy > (y.solod...@gmail.com) _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list