[fdo-trac] #498: OgrProvider - Stability (Managed Wrappers)

[FDO]

#498: OgrProvider - Stability (Managed Wrappers)
----------------------------+-----------------------------------------------
   Reporter:  pielera       |       Owner:  traianstanev
       Type:  defect        |      Status:  new         
   Priority:  critical      |   Milestone:  3.4.0       
  Component:  OGR Provider  |     Version:  3.4.0       
   Severity:  3             |    Keywords:              
External_id:                |  
----------------------------+-----------------------------------------------
 Quote:
   Ticket 415: Replace refcounting in OgrConnection by a better scheme
 involving overload of AddRef and Release. The code was written before
 AddRef and Release were virtual, so it had to use some hacks to do its
 job, and they are no longer necessary. It also *should* fix crashes during
 garbage collection when the provider is used via the managed wrappers (but
 this is just a guess).

 Well... It doesn't:

 {{{
 Attempted to read or write protected memory. This is often an indication
 that other memory is corrupt.
    at OSGeo.FDO.Connections.IConnectionImp.ReleaseUnmanagedObject()
    at OSGeo.FDO.Runtime.Disposable.Dispose()
    at ConsoleApplication1.Program.Main(String[] args) in
 D:\SOURCE\FDO_TEST\
 ConsoleApplication1\Program.cs:line 30
 }}}

 __Here the code to reproduce:__
 {{{
 using System;
 using System.Collections.Generic;
 using System.Text;

 namespace ConsoleApplication1
 {
     class Program
     {
         static void Main(string[] args)
         {
             try
             {
                 using (OSGeo.FDO.IProviderRegistry mRegistry =
 OSGeo.FDO.ClientServices.FeatureAccessManager.GetProviderRegistry())
                 {
                     using (OSGeo.FDO.IConnectionManager mgr =
 OSGeo.FDO.ClientServices.FeatureAccessManager.GetConnectionManager())
                     {
                         using (OSGeo.FDO.ClientServices.ProviderCollection
 col = mRegistry.GetProviders())
                         {
                             for (int k = 0; k < 10; k++)
                             {
                                 using (OSGeo.FDO.Connections.IConnection
 connection = mgr.CreateConnection("OSGeo.OGR.3.4"))
                                 {
                                     using
 (OSGeo.FDO.Connections.IConnectionInfo connInfo =
 connection.ConnectionInfo)
                                     {
                                         using
 (OSGeo.FDO.Connections.IConnectionPropertyDictionary connPropDict =
 connInfo.ConnectionProperties)
                                         {
                                             List<string> lst = new
 List<string>(connPropDict.PropertyNames);
                                         }
                                     }
                                 }
                             }
                         }
                     }
                 }
             }
             catch (Exception e)
             {
                 Console.WriteLine(e.Message);
                 Console.WriteLine(e.StackTrace);
             }
             Console.WriteLine("Finished");
             Console.ReadKey();
         }
     }
 }
 }}}

 I wasted endless hours on this problem but was unable to fix it. I ended
 up removing the "delete this;" from the OgrConnection::Dispose method for
 the time being. So I can, at least, continue my project and further tests.
 And I'm well aware that this change results in a memory leak.

 __Here are my findings about this problem so far:__
  * OgrConnection::m_refCount is not initialized anywhere in the current
 code
  * The crash only occurs with the OgrProvider release build (the debug
 build runs smoothly)
  * It crashes when multiple different WrapperClasses have a reference to
 the OgrConnection object (e.g. IConnection and IConnectionInfo)

 I really hope someone is able to fix this and so a stable FDO 3.4.0 can be
 released.

 PS: As a last resort the OgrConnection can be split in multiple classes
 like the other providers if the refcounting-thingie is the problem.
 IMHO the refcounting part looks perfectly fine except for the refcount-
 initialization... but something is definitely wrong.

-- 
Ticket URL: <http://trac.osgeo.org/fdo/ticket/498>
FDO <http://fdo.osgeo.org/>
Feature Data Objects