One thing I did which seems to largely eliminate the problem is to adjust the GC to just track threads that are registered. This is quite a change from current behavior of tracking all threads, so I never submitted the changes upstream. It seems to alleviate the issue as sometimes threads may be executing in kernel mode, or be in some weird state where their context cannot be retrieved. In practice the threads in question have never been a 'mono' thread executing managed code, but other random threads. Thus the GC does not try to pause/inspect/resume these threads and seems much more robust.<div>
<br></div><div>I'll look at cleaning up the patch and posting on my branch if not submitting for upstream.<br><div><br></div><div>- Jonathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 11:16 AM, Frank Fuchs <span dir="ltr"><<a href="mailto:fk.fuchs@googlemail.com" target="_blank">fk.fuchs@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Robert,<br>
<br>
the GetLastError() returns 31. I think I use lazy-loading - I just put<br>
the libgc-1.dll in the apps folder as well as libmono-2.dll.<br>
So what would you suggest instead?<br>
<br>
Thank you! Best,<br>
Frank<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</div></div></blockquote></div><br></div>