[fdo-users] Memory leaks - lots of them ?

[Oyvind Idland]

Here is a brief track of a couple of leaks.


{12783} normal block at 0x0D09DCC0, 52 bytes long.
 Data: <D e f a u l t   > 44 00 65 00 66 00 61 00 75 00 6C 00 74 00 20 00
{12782} normal block at 0x0D09DC50, 52 bytes long.
 Data: <R P J U R I D I > 52 00 50 00 4A 00 55 00 52 00 49 00 44 00 49 00


These are two strings, allocated here:

Fdo\Unmanaged\Src\Fdo\Schema\FeatureClass.cpp:
FdoFeatureClass* FdoFeatureClass::Create(FdoString* name, FdoString*
description)
{
  return new FdoFeatureClass(name, description);
}


Further down the callstack:

Utilities\Common\Src\FdoCommonSchemaUtil.cpp:
FdoFeatureClass *
FdoCommonSchemaUtil::DeepCopyFdoFeatureClass(FdoFeatureClass * sourceClass,
FdoCommonSchemaCopyContext * schemaContext)
{
   FdoPtr<FdoFeatureClass> newClass =
FdoFeatureClass::Create(sourceClass->GetName(),
sourceClass->GetDescription());
   ....
   FDO_SAFE_ADDREF(newClass.p);
   return newClass;
}


d:\src\o\FDO\Utilities\Common\Src\FdoCommonSchemaUtil.cpp
FdoClassDefinition *
FdoCommonSchemaUtil::DeepCopyFdoClassDefinition(FdoClassDefinition *
sourceClass, FdoCommonSchemaCopyContext * schemaContext)
{
    newClass =
DeepCopyFdoFeatureClass(static_cast<FdoFeatureClass*>(sourceClass),
schemaContext);
...
    FDO_SAFE_ADDREF(newClass.p);
    return newClass;
}


Providers\ArcSDE\Src\Provider\ArcSDEDescribeSchemaCommand.cpp:
void ArcSDEDescribeSchemaCommand::cloneClassDefinitions(FdoStringCollection*
qFCNames, FdoFeatureSchemaCollection* retSchemaCol,
FdoFeatureSchemaCollection* schemaCol):
{
        classes = retSchema->GetClasses();
.....
        classDef = FdoCommonSchemaUtil::DeepCopyFdoClassDefinition(classDef,
NULL);
        FDO_SAFE_ADDREF(classDef.p);
        classes->Add(classDef);
}


I find this all a bit difficult to sort out, but could it be all the
addref's, and the possibility that the classes collection
doesn't free resources properly ?

I have also looked through the our code (using .NET wrapper) , and there is
using() statments on all references.

Note that I get about 140 leaks in this example, using only 1 layer/dataset.



-- Oyvind









On Tue, Feb 22, 2011 at 5:07 PM, Oyvind Idland <oyvind.idland at gmail.com>wrote:

> I tracked just one leak, and it appears to come from the FDO framework
> itself.
>
> I'm not in my office right now, but I also saw a SAFE_ADDREF macro or
> something
> like that being used on the same pointer during the callstack, could it be
> ref's that doesn't
> get released ? (didn't study in detail)
>
>
> -- Oyvind
>
>
>
> On Tue, Feb 22, 2011 at 4:39 PM, Greg Boone <greg.boone at autodesk.com>wrote:
>
>>  The FDO API is fairly good when it comes to controlling memory. The
>> ArcSDE provider itself may not be as efficient. If you have any details,
>> please send them and/or create a trac ticket.
>>
>>
>>
>> Greg
>>
>>
>>
>> *From:* fdo-users-bounces at lists.osgeo.org [mailto:
>> fdo-users-bounces at lists.osgeo.org] *On Behalf Of *Oyvind Idland
>> *Sent:* Tuesday, February 22, 2011 10:18 AM
>> *To:* FDO Users Mail List
>> *Subject:* [fdo-users] Memory leaks - lots of them ?
>>
>>
>>
>> I get lots of memory leaks when debugging the trunk code.
>>
>> Is there being done any checks for leaks by the coders ?
>>
>> Let me know if you need some more info.
>>
>>
>>
>> -- Oyvind
>>
>> _______________________________________________
>> fdo-users mailing list
>> fdo-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20110223/2b0b0b8f/attachment.html