[Mono-dev] mono crash on exits when using COM.
tom hindle
tom_hindle at sil.org
Tue Jan 26 12:26:19 EST 2010
Thanks for the info.
I will try running our nunit tests with '--domain=none' and see if this
improves matters, as our application itself doesn't create multiple
AppDomains.
Thanks
Tom
On Tue, 2010-01-26 at 11:42 -0500, Jonathan Chambers wrote:
> Tom,
> I don't think domains were completely taken into account when
> the COM Interop code was written. This will probably need looked into.
>
>
> Thanks,
> Jonathan
>
> On Tue, Jan 26, 2010 at 11:35 AM, tom hindle <tom_hindle at sil.org>
> wrote:
> It looks like a domain issue:
>
> I wrapped my test code in:
>
> AppDomain domain = AppDomain.CreateDomain("MyDomain");
> domain.ExecuteAssembly("GCTestLib.exe");
> AppDomain.Unload(domain);
>
> and as segv is produced because the ccw are freed before
> cominterop_release_all_rcws is called.
>
>
>
> On Tue, 2010-01-26 at 09:14 -0700, tom hindle wrote:
> > Bill,
> >
> > Change (121114) cominterop_release_all_rcws is still in and
> functioning
> > ok.
> >
> > However the problem I am seeing seems to happen before
> > cominterop_release_all_rcws is called from mini_cleanup.
> >
> > the ccws are being freed from the finalize_domain_objects
> function:
> >
> > #2 0x00000000004dcf2e in mono_marshal_free_ccw
> (object=0x7ffff4450700)
> > at cominterop.c:2067
> > #3 0x00000000004da310 in mono_gc_run_finalize (obj=<value
> optimized
> > out>, data=<value optimized out>) at gc.c:197
> > #4 0x00000000004da4c7 in finalize_domain_objects
> (unused=<value
> > optimized out>) at gc.c:984
> > #5 finalizer_thread (unused=<value optimized out>) at
> gc.c:1039
> > #6 0x0000000000500c46 in start_wrapper (data=<value
> optimized out>) at
> > threads.c:721
> > #7 0x000000000059afb3 in thread_start_routine
> (args=0x987a50) at
> > wthreads.c:286
> > #8 0x00000000005c0d0f in GC_start_routine
> (arg=0x7ffff7e88e70)
> >
> > before cominterop_release_all_rcws is called.
> >
> > Also I can only seem to reproduce the fault in a NUnit test.
> The
> > identical code in a main block doesn't seem to show the
> error.
> >
> > I'm wondering if it has anything to do with Application
> domain's?
> >
> > Thanks,
> > Tom
> >
> > On Sat, 2010-01-23 at 12:48 -0500, Bill Holmes wrote:
> > > Tom,
> > >
> > > I beleive that we had a problem with this before and I
> applied a fix.
> > >
> http://anonsvn.mono-project.com/viewvc?view=revision&revision=121114
> > >
> > > IIRC this code/fix should release all outstanding rcws
> before the
> > > final collect of other mono objects, including ccws.
> > >
> > > Can you investigate if this change (121114) has been
> broken, or needs enhanced?
> > >
> > > -bill
> > >
> > > On Fri, Jan 22, 2010 at 8:26 PM, tom hindle
> <tom_hindle at sil.org> wrote:
> > > >
> > > > I have added a check in mono_gc_run_finalize (void *obj,
> void *data)
> > > > (gc.c):
> > > >
> > > > ---
> > > >
> > > > if (suspend_finalizers)
> > > > return;
> > > >
> > > > + if (mono_marshal_ccw_refcount(o) > 0)
> > > > + {
> > > > + return;
> > > > + }
> > > >
> > > > domain = o->vtable->domain;
> > > >
> > > > ----
> > > >
> > > > This seems to solve the problem. The ccw isn't freed,
> which means when
> > > > the rcw releases its reference to the ccw, so it no
> longer segv's.
> > > >
> > > > Does this seem like an valid approach? I'm not sure If
> this means that
> > > > finalize_domain_objects needs to make multiple passes at
> freeing the
> > > > ccw's? I guess this change would also mean the badly
> written native COM
> > > > objects would prevent ccw from being freed. Is this a
> problem?
> > > >
> > > > Thanks
> > > > Tom
> > > >
> > > >
> > > > On Fri, 2010-01-22 at 16:16 -0700, tom hindle wrote:
> > > > > Hi all,
> > > > >
> > > > > I have been investigating some seemingly random crash
> on exit problems
> > > > > that our application has been having.
> > > > >
> > > > > I have managed mostly reliably to reproduce the issue
> by following this
> > > > > set of steps:
> > > > >
> > > > > 1. Create a managed object ManagedObj
> > > > > 2. Create a COM object COMObj for which its rcw is
> likely to be Garbage
> > > > > collected after ManagedObj and during mono shutdown.
> > > > > 3. Make COMObj contain a ref to ManagedObj's ccw
> > > > > 4. Set ManagedObj ref to null
> > > > > 5. Call GC.Collect() to encourage GC.
> > > > >
> > > > > If Garbage Collection of COMObj's rcw happens after
> the Garbage
> > > > > Collection of ManagedObj's ccw, then when COMObj calls
> Release on its
> > > > > ref to ManagedObj's ccw a segv is produced.
> > > > >
> > > > > Normally it seems that ref counts for the wrappers are
> respected,
> > > > > however this doesn't seem to be the case on program
> shutdown.
> > > > >
> > > > > Some pseudo code which reproduces the problem:
> > > > >
> > > > > public class TestComRelease
> > > > > {
> > > > > static COMObj cObj;
> > > > >
> > > > > [Test]
> > > > > public void Test()
> > > > > {
> > > > > ManagedObj mObj = new ManagedObj()
> > > > > cObj = new COMObj();
> > > > > cObj.SetManagedRef(mObj);
> > > > > mObj = null;
> > > > > GC.Collect();
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > I am attempting to find the cause of this in mono. Any
> pointers would be
> > > > > grateful received.
> > > > >
> > > > > Thanks
> > > > > Tom
> > > > >
> > > > > _______________________________________________
> > > > > 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
> >
> >
> > _______________________________________________
> > 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
>
>
>
More information about the Mono-devel-list
mailing list