[fdo-internals] SDF 3.0 FDO Provider Serious Memory Leak

[Carl Jokl]

The testing code is running in the .Net managed environment yes. The test
code was written in C# .Net. I am aware that it seemes the .Net API objects
are just thin wrappers around the C++ native ones. In that regard when
testing in a .Net envirionment it is not very easy if possible at all to see
what is going on in the native code. 

>From my point of view I think it a shame more of the API couldn't be
implemented in pure .Net. i.e. porting the C++ code into .Net instead of
just using .Net to wrap existing native code. I can see practical issues in
that it means maintaining multiple code streams and duplicating code in more
than one place.

I do have access to the C++ source code and I can write native C++ well
enough to be able to read the C++ source code and have an idea what is going
on. I thought a problem like this though may have already been spotted by
others.

I has been frustrating working with FDO in that it can seem when it comes to
providers if it is not one problem it is another. SDF was chosen as the
provider of choice for static data as the PostGIS provider benchmarks came
back so slow. Now discovering this big memory leak in the SDF provider is
not the best. We will be testing SQL Server FDO as well in due course and
hope that doesn't also end up having issues.
-- 
View this message in context: http://www.nabble.com/SDF-3.0-FDO-Provider-Serious-Memory-Leak-tp18447913p18448283.html
Sent from the FDO Internals mailing list archive at Nabble.com.