GetFunctionPointerForDelegate does produce a wrapper that checks if the
thread is attached
before entering managed.
On Mon, Jan 28, 2013 at 10:00 PM, sebast...@palladiumconsulting.com wrote:
We are not using the debugger.
We're not sure how the library in question creates its threads. We
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
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
Thanks for confirming Rodrigo.
On Jan 29, 2013, at 6:43 AM, Rodrigo Kumpera kump...@gmail.com wrote:
GetFunctionPointerForDelegate does produce a wrapper that checks if the
thread is attached
before entering managed.
On Mon, Jan 28, 2013 at 10:00 PM, sebast...@palladiumconsulting.com
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
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
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
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
