[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