2

I'm having a bit of a memory leak, or more like a memory sieve really.

I'm working in C++ and I'll illustrate what's happening with one iteration of part of my program.

I have an IGeometryPtr, and for this case it is pointing to an IPolygon with ~700,000 points in it (the issue is present, but less pronounced with smaller geometries). All is good and well until I attempt to extract point or ring information from it. At that point my memory use spikes way up (which is to be expected at this point). The issue is that a chunk of that memory is never released. I'll usually lose about 100 MB on this gigantic geometry. Here's the code:

void ShortLengthSegmentHelperNative::loopPolygonParts(IPolygon4Ptr polygon, void* arg1, void* return1, void (ShortLengthSegmentHelperNative::*f)(IGeometryPtr, void*, void*, bool&))
{
    long extRingCount;
    polygon->get_ExteriorRingCount(&extRingCount);

    //If I return here there is no leak!!!

    IRing** extRings = new IRing*[extRingCount];
    polygon->QueryExteriorRingsEx(extRingCount, extRings);

    //Leak appears to be the same size regardless of releasing the Rings
    for (int i = 0; i < extRingCount; i++)
    {
        extRings[i]->Release();
    }
    delete[] extRings;
    //lose 100 MB when returning here
    return;
    //...stuff to do when this is fixed
}

I should note that this also happens if I retrieve the geometry bag instead of using QueryExteriorRingsEx. The polygon shouldn't need to be released because it's a smart pointer and will release itself.

Does anyone know why this code leaks memory? This is ArcObjects 10.2

  • 3
    What is your question? Have you contacted Esri Tech Support? You'll need to specify the exact release of ArcGIS in use. – Vince Jan 31 '17 at 0:04
  • Have you looked at this earlier thread? – Hornbydd Jan 31 '17 at 0:05
  • It appears my last line was edited out. I'm asking if anyone knows why accessing this geometry and then later releasing that geometry causes my program to leak 100 MB of memory. I'm asking if there's something that needs to be done to further dispose of these com objects. – danielm Jan 31 '17 at 15:15
  • Hornbydd - That thread doesn't seem to address my issue. The memory leak occurs even when I get the rings via IGeomteryBag. – danielm Jan 31 '17 at 15:31
  • My C/C++ COM is a bit rusty, but if I remember correctly, when you call Release you are only decreasing the reference count by 1. The object is only unallocated/released when that count reaches 0. While you are correct in that the polygon doesn't need to be released (in this function), it's possible that it's holding references to the IRings that are being created. You may want to try releasing the polygon after this function call to see if that's the case. – Evil Genius Jan 31 '17 at 16:22
1

The issue appears to have been smart pointer not acting as I expected them to and throwing off the ref count of my objects.

In my code I had a call the following code

void ShortLengthSegmentsHelper::LoadGeometry(ESRI::ArcGIS::Geometry::IGeometry^ shapeGeometry, ...)
{
    IGeometryPtr shapePtr((IUnknown*)void*)Marshal::GetIUnknownForObject(shapeGeometry));
    IPolygon4Ptr polyShapePtr(shapePtr);
    ...
}

What I expected to have happen is that code would increment ref count on shapeGeometry twice, and then decrement the ref count twice when leaving the function. This wasn't correct and this object kept all the sub-geometries of this geometry open as well.

Instead I simply needed to add

shapePtr->Release();

to the end of the method, so that the object could be freed correctly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.