Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Can anyone else reproduce the memory leak described below? Any insight into what may be causing the leak is appreciated.

I have custom code that swaps between landscape and portrait templates and exports a large number of maps to PDF. Unfortunately, there is a memory leak occurring when I swap from template to template that eventually causes the ArcMap to crash.

I can reproduce the memory leak using the Minerville data and workflow described below.

Configuration:

ArcFM Solution Desktop 10.1

ArcGIS 10.1 for Desktop 10.1

Windows 7 64-bit or Windows XP 32-bit or Windows 2008 64-bit

Workflow:

1) Open Minerville database in ArcMap

2) Open “Stored Items” dropdown

3) Select “Page Templates” tab

4) Double-click the “Adjacent Grids” template to load it

5) Repeat steps 2-3 and double-click “Designer Detail Map Sheet”

6) Repeat steps 2 – 5 and watch memory usage climb in task manager

Using UMDH, the largest ArcFM-related offenders seem to be these:

Stack #1:

ntdll!RtlAllocateHeap+00000274
KERNELBASE!LocalAlloc+0000005F
GDI32!pmfAllocMF+0000018C
GDI32!SetEnhMetaFileBits+00000033
OLEAUT32!_PictLoadUnknownMetaFile+00000088
OLEAUT32!_PictLoadNewImage+000001A0
OLEAUT32!_PictLoadPicture+00000025
OLEAUT32!CPicture::Load+00000027
SystemCore!ObjectStream::LoadObject+000003E9
AfCore!LoadObject+0000005E
RasterGraphicElements!BasePictureElement::Load+000000ED
SystemCore!ObjectStream::LoadObject+000003E9
AfCore!LoadObject+0000005E
AfCore!ExtraSafeReadObject+00000072
PageLayout!PageLayout::Load+00000174
SystemCore!ObjectStream::LoadObject+000003E9
MMStoredStuff!DllGetClassesForCategoryReg+00011B32
MMStoredStuff!???+00000000 : 2DB04186
MMStoredStuff!DllGetClassesForCategoryReg+0000D9E5
MMStoredStuff!DllGetClassesForCategoryReg+0000C297
mmPageTemplatesUI!DllCanUnloadNow+00020402
mmPageTemplatesUI!DllCanUnloadNow+00038EAF
mmFrameworkListObjects!DllGetClassesAndCategories+000C38DC
mscorwks!CLRToCOMWorker+0000019A

Stack #2:

ntdll!RtlAllocateHeap+00000274
MSVCR90!malloc+00000079
MSVCR90!operator new+0000001F
DisplayCore!ClassFactory<CartographicLineSymbol>::CreateInstance+000000D8
AfCore!FactoryCache::CreateInstance+00000095
AfCore!FactoryCacheDispatcher::CreateInstance+00000050
AfCore!AfCreateInstance+00000040
SystemCore!ObjectStream::LoadObject+00000297
AfCore!LoadObject+0000005E
DisplayCore!MultiLayerLineSymbol::Load+000000F8
SystemCore!ObjectStream::LoadObject+000003E9
AfCore!LoadObject+0000005E
GraphicElements!LineElement::Load+00000076
SystemCore!ObjectStream::LoadObject+000003E9
AfCore!LoadObject+0000005E
GraphicElements!GroupElement::Load+00000082
SystemCore!ObjectStream::LoadObject+000003E9
AfCore!LoadObject+0000005E
AfCore!ExtraSafeReadObject+00000072
PageLayout!PageLayout::Load+00000174
SystemCore!ObjectStream::LoadObject+000003E9
MMStoredStuff!DllGetClassesForCategoryReg+00011B32
MMStoredStuff!???+00000000 : 2DB04186
MMStoredStuff!DllGetClassesForCategoryReg+0000D9E5
MMStoredStuff!DllGetClassesForCategoryReg+0000C297
mmPageTemplatesUI!DllCanUnloadNow+00020402
mmPageTemplatesUI!DllCanUnloadNow+00038EAF
mmFrameworkListObjects!DllGetClassesAndCategories+000C38DC
mscorwks!CLRToCOMWorker+0000019A

UPDATE #1:

Schneider Electric's support was able to reproduce the problem and has created a bug. I was told that if a fix was made at all, it would not be available until the 10.2 release.

I'll post more as I get more information.

share|improve this question
    
+1 for showing usefulness of UMDH. –  Kirk Kuykendall Mar 21 '13 at 14:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.